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