[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Precedence for reader extensions
From: |
Mikael Djurfeldt |
Subject: |
Re: Precedence for reader extensions |
Date: |
Fri, 22 Feb 2013 10:36:27 +0100 |
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
- Re: Precedence for reader extensions, (continued)
- Re: Precedence for reader extensions, Mikael Djurfeldt, 2013/02/18
- Re: Precedence for reader extensions, Mikael Djurfeldt, 2013/02/18
- Re: Precedence for reader extensions, Mark H Weaver, 2013/02/18
- Re: Precedence for reader extensions, Mikael Djurfeldt, 2013/02/19
- Re: Precedence for reader extensions, Mark H Weaver, 2013/02/19
- Re: Precedence for reader extensions, Mikael Djurfeldt, 2013/02/19
- Re: Precedence for reader extensions, Mikael Djurfeldt, 2013/02/19
- Re: Precedence for reader extensions, Ludovic Courtès, 2013/02/20
- Re: Precedence for reader extensions, Mark H Weaver, 2013/02/21
- Re: Precedence for reader extensions,
Mikael Djurfeldt <=
- Re: Precedence for reader extensions, Ludovic Courtès, 2013/02/22
- Re: Precedence for reader extensions, Ludovic Courtès, 2013/02/22
- Re: Precedence for reader extensions, Mikael Djurfeldt, 2013/02/19