Email list hosting service & mailing list manager

Re: SRFI 105: Curly-infix-expressions Alan Manuel Gloria (26 Aug 2012 21:38 UTC)
Re: SRFI 105: Curly-infix-expressions John Cowan (26 Aug 2012 22:04 UTC)
Re: SRFI 105: Curly-infix-expressions Alan Manuel Gloria (26 Aug 2012 22:23 UTC)
Re: SRFI 105: Curly-infix-expressions John Cowan (26 Aug 2012 22:39 UTC)
Re: SRFI 105: Curly-infix-expressions David A. Wheeler (27 Aug 2012 00:04 UTC)
Re: SRFI 105: Curly-infix-expressions Alan Manuel Gloria (26 Aug 2012 22:11 UTC)

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