Re: Precedence for reader extensions

[Mikael Djurfeldt]

Thanks, Mark.  This all sounds very sensible to me, and I will
continue working on the scmutils port while waiting for your patch.

On Fri, Feb 22, 2013 at 3:52 AM, Mark H Weaver <address@hidden> wrote:
> Mikael Djurfeldt <address@hidden> 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 <address@hidden> 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 <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.
>
> 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.
>
>      Regards,
>        Mark