Re: Precedence for reader extensions

[Ludovic Courtès]

Mark H Weaver <address@hidden> skribis:

> Ludovic Courtès <address@hidden> 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.

The DSSSL option could be documented as incompatible with those other
reader options, and perhaps an error could be raised when an attempt to
use incompatible options is made.  WDYT?

Admittedly, this would increase reader complexity.

> Ludovic Courtès <address@hidden> 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.

Probably parser combinators, like
<http://planet.racket-lang.org/display.ss?package=combinator-parser.plt&owner=plt>.

In Guile we have the extra restriction that we need to keep ‘read’ in C
for bootstrapping, so that would probably mean having two reader
implementations.

Ludo’.