[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:36:45 +0900
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (darwin)

>>>>> "Tobia" == Tobia Conforto <address@hidden> writes:

    Tobia> 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.
    >> The way this would work is that, naturally, if you
    >> wanted to use utf8 semantics you'd just (use utf8),
    >> this time with no need for syntax-case and nothing to
    >> import.
    >> 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))

    Tobia> This seems very straightforward and natural.
    Tobia> What are the disadvantages, if any?  (except for
    Tobia> compatibility, aka. tremendous breakage as Felix
    Tobia> put it)

    Tobia> I mean, what does the syntax-case module system
    Tobia> gives us with regard to the utf8 egg that the
    Tobia> proposed, numbers-like system wouldn't allow?
    Tobia> Why was it done like that in the first place?

When it was originally written, it would indeed have
incurred tremendous breakage, because most string operations
were not inlined.  It really wasn't even a consideration.

When Felix says it would incur tremendous breakage now, I
believe he's referring to the fact that people who are
currently using utf8 are all writing:

(use utf8)
(import utf8)

and now they'll have to remove the import line from their
existing code.  Since we've just gone 3.0, now seems like
the ideal time to induce such breakage though.

There will also likely be minor breakage in obscure areas,
all of which can be worked around.  Since everyone who has
responded seems to be importing utf8 into the top-level
anyway, this is all around cleaner and much more

Anyway, I've just checked in the new version, so you're
stuck with it :) The new rule is much simpler - eggs that
want utf8 semantics just say

(use utf8)

and nothing else is effected (except the top-level when
running in the interpreter).

If you *want* an egg to see the utf8 semantics, but only
when they've been loaded from somewhere else, compile that
egg with

(declare (not usual-integrations))

I'll be ready to respond to the curses and bug reports as
they come in :)


reply via email to

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