This page is part of the web mail archives of SRFI 105 from before July 7th, 2015. The new archives for SRFI 105 contain all messages, not just those from before July 7th, 2015.
On Mon, Aug 27, 2012 at 6:39 AM, John Cowan <cowan@xxxxxxxxxxxxxxxx> 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