[Ecls-list] Automatic string conversion - wanted or needed?

[Matthew Mondor]

On Sat, 26 Apr 2014 20:26:43 +0200
"Philipp Marek" <philipp at marek.priv.at> wrote:

> Now, my question - is it okay to remove the type conversion as
> in the attached patch? Or should it be kept that way, because
> of some CL requirements?
>   (I checked SBCL, ABCL, and CLISP - all of these return
>    CHARACTERS for _both_ of the above TYPE-OF forms.)

A possible issue might be when using the native FFI facilities and
C-application-embedding, where C can be provided, or easily generate
base strings (which are just ASCII in ECL's case).  The alternative
would be to explicitely convert from/to UTF-8 byte vectors, because
CHARACTER is not C-friendly, unless the C application expects UCS4 (or
UTF-8 with care and some FFI overhead).

Of course, it's always possible to also explicitely create
base-strings or attempt to coerce to base-strings, so I'm not sure yet
how pervasive the change would be.

I should check if in my code base I have such expectations, especially
that I was aware that ECL is doing this conversion automatically, and
I do not use other implementations much.

Another thing to check is if this affects the reader, which currently
imports symbols as base strings.  Sorry for not being able to
immediately do this myself.  But thanks for first proposing the change
here before committing it.

The last aspect might be saving some memory and enhancing performance
in the common case by using single-byte strings, but arguably one could
say that if consing a lot, the check and conversion might also be
considered overhead.
-- 
Matt