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

[Robin Lee Powell]

On Tue, Mar 11, 2008 at 05:05:27PM +0900, Alex Shinn wrote:
> >>>>> "Robin" == Robin Lee Powell <address@hidden> writes:
>     Robin> On Thu, Jun 28, 2007 at 12:25:54PM +0900, Alex Shinn wrote:
> 
>     >> I'm considering changing the utf8 egg to no longer
>     >> use syntax-case modules, so that it would work like
>     >> the numbers egg.
>     [...]
> 
>     Robin> Perhaps I'm missing something, but I *really*
>     Robin> don't like the idea of having to manage my own
>     Robin> personal versions of spiffy and all of its
>     Robin> dependencies just to get utf8 support.  That
>     Robin> seems really sub-optimal.
> 
> I'm not entirely sure why you think spiffy would need two
> versions.

Because you said:

    External modules, by default, would integrate standard string procedures
    and not be affected.  However, if you wanted to make an extension
    optionally work with utf8 semantics you could compile it with

    (declare (not usual-integrations))

    or alternately

    (declare (not usual-integrations string-ref string-set! ...))

    for all the utf8-specific string procedures.

which I interpret as meaning that the eggs need to be recompiled
that way.

> First, are you referring to the syntax-case version of utf8 or the
> new version that would globally redefine string operations?

The new version.

> Second, does spiffy itself do any operations on strings where it
> would matter whether the strings were utf8 or not? 

I would have assumed so, but...

> I somehow doubt this.  I could easily see individual extensions or
> servlets needing this behavior, but in either the old or the new
> approach those extensions could just use utf8 themselves, without
> any need to change spiffy.
> 
> I think possibly the utf8 string representation may be confusing
> some people though.  Basically, when using the utf8 egg, all
> Chicken strings are considered to be utf8 encoded.  However, code
> compiled with the default integrations will treat them essentially
> as byte-vectors, ignoring utf8 semantics.  For parsing URI's, or
> handling pathnames, or most common tasks that spiffy would do,
> *either* assumption works.

Aaaaah.  Well, in that case, that's not so bad.

> But I want to ask again, do people want this, and is it OK to
> break compatibility in the current utf8 egg?

At this point, I have no opinion either way; I'm not far enough into
my coding for compatibility issues to bother me at all.

-Robin

-- 
Lojban Reason #17: http://en.wikipedia.org/wiki/Buffalo_buffalo
Proud Supporter of the Singularity Institute - http://singinst.org/
http://www.digitalkingdom.org/~rlpowell/ *** http://www.lojban.org/