[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SRFI 105: Curly-infix-expressions

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.