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 5:44 AM, John Cowan <cowan@xxxxxxxxxxxxxxxx> wrote:
> Alan Manuel Gloria scripsit:
>
>> Perhaps we'll clarify in the SRFI that an implementation *must
>> not* provide `nfx` (with the exception that a *future* SRFI *may*
>> mandate that implementations provide `nfx` at some level).
>
> -1
>
> An implementation might, for example, want to provide nfx as a macro
> which looks for user-written precedence definitions and does the Right
> Thing with them. This ought not to be forbidden. Just like any
> other identifier provided by an implementation, the user would be
> free to redefine it, after all.
Okay, how about:
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.
However, an implementation *may* provide a *library* that binds
the `nfx` symbol (as it is then a library, it actually falls under the
"reserved for use by library writers" clause above). Application
writers and other library writers are then free to use or not use
the implementation's provided `nfx` implementation.
A later SRFI *may* mandate that an implementation bind `nfx`
to some procedure, macro, or syntax; we expect such an SRFI
to be proposed, ***if ever***, after some actual experience has
been had by the Scheme community with using this SRFI.
--
Is that better?
We want to make it clear that nfx is a hook provided for users
of the implementation, not something that allows the
implementation to mandate any kind of precedence. Any
library provided by some implementation then becomes just
a sort of "suggestion" or "proposal" for whatever precedence
system the Scheme community as a whole should offer.
We thought to make this SRFI proposal now, before a
precedence system is settled upon (if ever) so that
we can reserve the symbols "{" and "}" before it's taken for
some other syntax.
--
I (not speaking as an author of this SRFI anymore) am
personally convinced that precedence is a color of the
bikeshed issue. By cutting out precedence, I hope to
get agreement to reserve "{" and "}" within the timeframe
of the SRFI process.
Sincerely,
AmkG