Re: keyword cleanup patch

[Richard Todd]

On Sat, Jan 10, 2004 at 10:18:22AM -0600, Stephen Compall wrote:
> Richard Todd <address@hidden> writes:
> 
> > Why are both syntaxes allowed in this one area, anyway?  I assume
> > it's a historical reason?  It's inconsistent with the rest of guile
> > (AFAIK) where you have to set a reader option for this behavior.
> 
> On the syntax: Emacs Lisp uses plain `:' for keywords; other lisps may
> do so as well.  Incidentally, `#:' in front of a symbol in elisp will
> prevent its interning. :)

That doesn't explain why special code in boot-9 allows #: or : in
specific statements like (define-module), does it?  I may not be fully
grasping what you are getting at.

I've searched with google, and the only explanation I can find is that
several guile developers prefer :.  I'm fine with that sentiment, but
guile's current state doesn't actually help these people, IMO.

The main problem, as I see it, is that people can't use : in code they
would release, because they can't assume that users are using the
optional reader setting.  Setting the option for the users would be
disgusting, and potentially break their code.

In my fledgling library of modules, I added a module which lets you do:

(define-module (xxx) :use-syntax (guile-syntax colon-keyword))

...and for this module you can code to your preference.  Users need
not even know about a reader extension (in fact, I took the extension
itself out of my local guile tree, on principle!).

To me, this is a sane answer.  Plus, this approach can be extended to
support 'keyword:' (as in DSSSL), or '&keyword', etc, without changing
the scheme reader.  Of course you take a speed hit compared to the
reader option, but there are ways to help with that if it became an
issue.

(And though I may be alone, and have not done any research on this
issue, I don't see why an elisp reader has to be grafted on to the
scheme reader.  Aside from the oh-so-close-to-scheme elisp case, if
guile really wants to seamlessly support other languages, it needs a
way to load a module with a different reader entirely, anyway.  A
separate elisp reader could still share code with the scheme reader, I
would think, and would be a cleaner answer).

The proof-of-concept (read: room for improvement!) module I described
is attached, for any who might be interested.

Richard Todd

colon-keyword.scm
Description: Text document

pgpoYv3FCvnrA.pgp
Description: PGP signature