Re: Precedence for reader extensions

[Mikael Djurfeldt]

On Tue, Feb 19, 2013 at 4:41 PM, Mark H Weaver <address@hidden> wrote:
> Mikael Djurfeldt <address@hidden> writes:
>> 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.
>
> I'm not sure that I consider this a bug.

In this reply I've attached a file mit-reader-scm which installs a
hash-read-procedure for #\!.

What I wanted to say above is that scm_read_sharp (in HEAD) is
implemented with the priorities I list above while flush_ws is
implemented with other priorities.  Here's a demo of the consequences
of this bug:

scheme@(guile-user)> (load "mit-reader.scm")
scheme@(guile-user)> (quote #!optional)
... !# hi)
$1 = hi
scheme@(guile-user)> '#!optional
$2 = #:optional

> [...]
> I'm uncomfortable with globally overriding standard read syntax.  In a
> large scheme system such as Guile, there are many modules that use
> 'read' and expect it to act in accordance with standard lexical
> conventions.

Well, in the mit-scheme compatibility module, my intention was to use
dynamic-wind to modify #!-syntax while loading mit-scheme-specific
files.  Note that %read-hash-procedures is a fluid, so this will be
absolutely local and won't leak out in any way to the rest of the
system.

> The problem with this approach is that it does not compose.

Let's now patch guile according to the diff I sent... there!

scheme@(guile-user)> (load "mit-reader.scm")
scheme@(guile-user)> (quote #!optional)
$1 = #:optional
scheme@(guile-user)> '#!optional
$2 = #:optional
scheme@(guile-user)> (quote #!hi!# #!optional)
$3 = #:optional

My take on this is:

* The %read-hash-procedures API is not pretty

* The suggested change doesn't make things prettier

* The suggested change *does* make things conceptually simpler and
more flexible (= you can always override hash syntax if you want;
compared to the current: you can override #| but not other hash
syntax)

* The suggested change fixes a bug

* The suggested change does compose and different syntax can be
confined to a module by using dynamic-wind

Best regards,
Mikael

mit-reader.scm
Description: Binary data