On Mon, Mar 17, 2008 at 10:07 AM, Alex Shinn <[EMAIL PROTECTED]> 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 _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
