Re: SRFI 105: Curly-infix-expressions
Alan Manuel Gloria 26 Aug 2012 21:59 UTC
On Mon, Aug 27, 2012 at 5:44 AM, John Cowan <xxxxxx@mercury.ccil.org> 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