Re: [PATCH] Per-module reader, take #3

From: Neil Jerram <neil@ossau.uklinux.net>
Cc: guile-devel@gnu.org
Subject: Re: [PATCH] Per-module reader, take #3
Date: Sat, 03 Dec 2005 20:02:32 +0000	[thread overview]
Message-ID: <8764q6kkyv.fsf@ossau.uklinux.net> (raw)
In-Reply-To: <87acg0maxs.fsf@zagadka.de> (Marius Vollmer's message of "20 Nov 2005 02:15:27 +0200")

Marius Vollmer <mvo@zagadka.de> writes:

> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> To be completely concrete about what I mean, here is a version of
>> your patch which I prefer (untested except by make check).
>
> Hmm.  Your approach make 'load' configurable so that it can use
> different 'read' procedures.  Wouldn't it be more natural to make
> 'read' configurable to parse different syntaxes?
>
> 'load' is only a thin wrapper around 'read' and 'eval' (basically, a
> repl without the 'p').  The real meat is in 'read' (syntax) and 'eval'
> (semantics).  So, if we want to customize the syntax, I'd say 'read'
> is the place to do it.  Then all users of 'read' would automatically
> use the new syntax, not only when reading code in 'load'.  (That's one
> big point of Lisp, that the data and code syntax are the same.)

That was my one of my first thoughts also (see towards the end of
http://lists.gnu.org/archive/html/guile-devel/2005-09/msg00035.html).
But now I'm not sure that it makes sense.  If you are reading
expressions by hand, and you want to use an alternative reader to do
so, you can just call (alternative-read port) - there's no need to
make the normal `read' configurable.

On the other hand, the reason for allowing `load' to be configurable
(with an alternative reader) is pretty much exactly the same as the
reason why we think it's useful to provide `load' at all: that is,
just that it's too boring to ask developers to write the same read
eval loop over and over again, even though they could.

Finally, although we might in theory be able to accommodate all
possible reading variants as configurable options to the default read,
in practice (i) this would be a pain for anyone wanting a variant that
hasn't yet been incorporated into Guile's official reader, because
they'd have to argue for it and then wait until it filtered through to
a release, and (ii) we'd still need to implement something to make it
easy to confine the effect/scope of read options to particular files,
because the common case is that particular files require particular
read variants.  Taking (i) and (ii), it seems a lot simpler just to
allow the Guile developer to specify an alternative read procedure for
a particular load operation.

> However, making the read procedure used by 'load' configurable can't
> hurt, I think.

OK, thanks.  I'll just wait a few days in case you or anyone else have
further comments.  If not I'll commit the patch as proposed.

Regards,
        Neil

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel