[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: |
Tue, 19 Feb 2013 17:58:14 +0100 |
On Tue, Feb 19, 2013 at 5:42 PM, Mikael Djurfeldt <address@hidden> wrote:
> * The suggested change does compose
What I meant here is that it does compose with the built-in syntax.
Of course, the %read-hash-procedures API by itself doesn't
automatically compose if multiple user-defined modules use it to
introduce new syntax. (If these modules take care to preserve
previously installed procedures, it can compose.)
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.
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. I regard my diff simply as a bug fix and cleanup (removing
unreachable code).
- Precedence for reader extensions, Mikael Djurfeldt, 2013/02/18
- 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 <=
- 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, 2013/02/22
- 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