On Mon, Aug 27, 2012 at 6:39 AM, John Cowan <xxxxxx@mercury.ccil.org> wrote:
> Alan Manuel Gloria scripsit:
>
>> The implementation *must not*, by default, bind the symbol `nfx`
>> to a procedure or macro; this symbol is reserved for use by library
>> writers and application writers.
>
> That still seems unnecessary to me.  In a library-based implementation,
> it makes no difference; in a flat namespace, the name can be overridden.

Okay, how can we best express the idea that "this SRFI does *not*
mandate that implementations provide a precedence system via
nfx, and implementations should generally reserve the nfx symbol
for use by library writers and application writers"?

nfx is a hook for users of the implementation.  That's what we want to
express.  Can you suggest a better way of saying it other than "this
symbol is reserved for use by library writers and application writers"?

Remember that this was inserted in response to Aubrey Jaffer worrying
that implementations are somehow allowed to *ipso facto* mandate a
particular precedence by providing an nfx implementation in the core
bindings of that implementation,  We the authors of the SRFI did not
intend nfx to be used in this manner: our intent was that nfx would
be used by library writers and application writers.

--

For that matter, I personally (almkglor) think that
curly-infix cannot, in practice, be *reliably* implemented
as a library on many actual Scheme implementations.

Our first implementation was on Guile.  On Guile 2.0, however, I
(almkglor) found that turning off autocompilation *disabled* the
curly-infix reader when loading a *module* (but not when using
'load or entering into the REPL).  This was exceedingly
strange behavior, as it worked perfectly fine with autocompilation
*enabled*.

It turns out that the module-loading code in the C side of 2.0 -
which is used *only* when autocompilation is turned off - called
the C implementation of read *directly*; rebinding 'read did *not* work
for this case.  When autocompilation is turned on, Guile 2.0
had this system for managing "languages", which was implemented
mostly in Scheme, so rebinding 'read *did* work for the autocompilation
case.

In Guile 1.8 the C code for module loading correctly referred to
the Scheme binding for 'read, so this bug was not discovered by
David A. Wheeler, who uses Guile 1.8 exclusively.

--

Another reason for mandating this is the above experience.

Rebinding 'read did not work for some edge case on an actual
Scheme implementation (Guile 2.0).  So I think that it's
possible that a similar mistake may be committed by another
Scheme implementation if they make a core binding for
`nfx`.  For instance, they might make their `nfx` a syntax
recognized by their interpreter or translator, in much the same
way that it's not possible to change the syntax of `lambda` by
rebinding its macro binding.

Specifically mentioning that `nfx` is intended for use by library
writers and application writers should help Scheme implementations
ensure that rebinding and/or limiting the scope of `nfx` does
work properly, as intended in this SRFI.

Sincerely,
AmkG