[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alex Shinn
Subject: Re: [Chicken-users] ditching syntax-case modules for the utf8 egg
Date: Sat, 15 Mar 2008 02:25:38 +0900
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (darwin)

>>>>> "Robin" == Robin Lee Powell <address@hidden> writes:

    Robin> On Tue, Mar 11, 2008 at 05:05:27PM +0900, Alex Shinn wrote:
    >> I'm not entirely sure why you think spiffy would need
    >> two versions.

    Robin> Because you said:

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

    Robin>     (declare (not usual-integrations))

    Robin>     or alternately

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

    Robin>     for all the utf8-specific string procedures.

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

Oh, that's not new though - in the old utf8 egg you would
have needed two versions of spiffy anyway, the vanilla one,
and one which used syntax-case and did an (import utf8).

The new version actually makes this easier.  You can just
have one version of spiffy that does

  (declare (not usual-integrations))

and then it's up to the user or other eggs whether to load
utf8, thus causing spiffy to run with Unicode semantics.

You could even make this optional and let users who want
this install spiffy with

  chicken-setup -c -no-usual-integrations spiffy

Again, this particular case is moot because spiffy itself
doesn't care either way how strings are encoded.  Things
like the formatting eggs that work with individual
characters and string-lengths might want to consider
disabling integrations on string operations.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]