Re: Precedence for reader extensions

[Mark H Weaver <mhw@netris.org>]

Mikael Djurfeldt <mikael@djurfeldt.com> writes:
> The API you suggest would compose much easier, but to me it feels like
> just another specialized solution.  What we would really need is
> something like Ludovic's guile-reader.

I agree that we should ideally have a much more general way of defining
customized readers.  In the meantime, my primary concern is to find a
solution to your problem without committing us to supporting an overly
general mechanism that fails to provide basic guarantees to other users
of 'read'.

As you pointed out, the current code *almost* supports overriding
standard syntax for things like "#!".  However, it has been broken for
a long time.  The same bug is in Guile 1.8, and I haven't seen anyone
complaining about it.  Therefore, I'm more inclined to remove this
broken functionality than to fix it.

Mikael Djurfeldt <mikael@djurfeldt.com> writes:
> But I won't be stubborn regarding this.  If someone else wants to
> implement another way of supporting #!optional and #!rest that is fine
> by me.

Thanks.  I hope to cook up a patch in the next few days.

Ludovic Courtès <ludo@gnu.org> writes:
> This is basically DSSSL keyword syntax.  What about adding a new keyword
> style to read.c?  Sounds like the easiest solution for this particular
> problem.

This is a tempting solution, but I see a problem with this proposal:
We'd have to make exceptions for things like #!fold-case and
#!curly-infix, as well as for things like #!/usr/bin/guile.  Also, it
could potentially turn existing scsh-style block comments into syntax
errors.

Ludovic Courtès <ludo@gnu.org> writes:
> In general, I think it should be easy to create new readers that derive
> from the standard syntax without having to write them from scratch.
> 
> However, in hindsight, I’m not sure Guile-Reader’s API is the right
> approach.  It’s an improvement, because it addresses this need; but its
> API is not ideal: “token readers” with different delimiter syntax don’t
> compose well, for instance.

I'd be very interested to hear your current thoughts on what a better
API should look like.

     Regards,
       Mark