[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 11:14:03 +0100 |
On Tue, Feb 19, 2013 at 12:33 AM, Mark H Weaver <address@hidden> wrote:
> Mikael Djurfeldt <address@hidden> writes:
>> I propose to simplify this to only two levels:
>>
>> 1. %read-hash-procedures
>> 2. predefined syntax
It turns out that the change I propose above was already implemented
in read.c. The effect just wasn't visible due to a bug in flush_ws
which caused all #! to be erroneously removed if they exist as the
outermost expression.
In the attached diff, I've fixed the flush_ws bug and cleaned up some
garbage code in scm_read_sharp which was unreachable.
Can I push this into the repository?
> I don't think this would be sufficient. The problem is that tokens of
> the form "#!<symbol><delimiter>" have become standardized. To name a
> few examples, both R6RS and R7RS define the reader directives
> #!fold-case and #!no-fold-case, R6RS has #!r6rs, and SRFI-105 has
> #!curly-infix. Guile also has #! ... !# block comments to help with the
> handling of executable scripts.
In what sense is it not sufficient? In any case: The present diff
doesn't remove any functionality or make performance worse. It only
removes some inconsistent behavior. At the same time it allows
support for mit-scheme #!optional and #!rest.
Best regards,
Mikael D.
reader-fix.diff
Description: Binary data
- 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 <=
- 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, 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