Re: [Chicken-users] ditching syntax-case modules for the utf8 egg

[felix winkelmann]

On Mon, Mar 17, 2008 at 10:07 AM, Alex Shinn <address@hidden> wrote:
>
>     Felix> No, integration only happens in operator
>     Felix> position.
>
>  Well, that's easy enough to change.

But won't, in the foreseeable future.

>
>     Felix> But won't syntax-case's module system rewrite the
>     Felix> variable reference, regardless whether the
>     Felix> identifier is in operator position or not?
>
>  Yes.  I see what you're saying though - importing into the
>  top-level doesn't actually mutate the top-level bindings of
>  the same name, so it won't be the same.  Except for
>  subsequently LOADed or EVALed code.  Yet another compiled
>  code vs. interpreted code difference.  Yet another reason
>  never to touch syntax-case modules :(
>
>  Anyway, I never used utf8 myself before (I always just used
>  utf8-lolevel directly, but that's really not recommended).
>  I will likely not use it in the future either.  The semantic
>  differences can be worked around between byte-strings and
>  utf8-strings, but because there is an abundance of code in
>  many libraries that need to refer to string indices it's
>  pretty much impossible to integrate any kind of code that
>  changes the meaning of those indices.
>

If nobody uses it, wouldn't it then be safer to keep the syncase module
and make sure accidental interferences cannot happen? Regarding
compiled-vs-interpreted: using syntax-case modules actually
reduces the difference between these two modes. By relying on
integration (which is used in the numbers egg as well, but for a
smaller and easier to understand set of primitives) the behaviour
of string operations is now dependent on optimization switches,
declarations and coding style. Very bad.


cheers,
felix