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

Re: Precedence

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 Tue, Sep 18, 2012 at 11:24 AM, David A. Wheeler
<dwheeler@xxxxxxxxxxxx> wrote:
> As promised, here's a precedence thread.
> I think precedence is overrated for an infix notation in Scheme.  In real code, more than two-thirds of actual examples didn't even mix operators, and thus by definition had no need for precedence.  In the rest, every different operator adds only two new characters, { and }, which would often be used anyway for clarity.  So while precedence support is *common* elsewhere, actual code use doesn't give much evidence for the utility of precedence in Scheme.  Expressions where it merely *might* be useful are probably less than 10% of all cases, given the sample set of actual code we have (posted earlier).
> That said, it *would* be possible to add support for precedence to curly-infix.  Such approaches are documented in the current SRFI draft, and code to do it is trivial.
> So, is adding precedence critically important to gain widespread implementation and use of curly-infix?  Would adding precedence harm its adoption?  Would it be a wash?  If you think precedence is critically necessary, what operators should be supported?  Are we just talking *, /, +, -  (I'll grant that everyone agrees on THEIR precedence and direction)?  More?  Why?  There are many options if we went down that road - what would be the principle to decide between them?  In particular: Would anyone use curly-infix *if* it had precedence, and *not* otherwise?
> I am not committing to add precedence (obviously),  indeed, I'm rather skeptical on the grounds that the additional complexity doesn't seem justified.  But I'd be curious to hear people's thoughts.



I feel somewhat more strongly than David here; I think
the extra complexity of precedence is much too much
work for far too little gain, and the current design of "no
precedence at all" gives the best value for your design

In particular, it's best to remember that one goal is
continued usability of current idioms.  For example,
Scheme has classically had char<? and friends, and I
would guess that it would be idiomatic in Scheme that,
if I made my own ordinal type, I would define type<?
and friends.  But if precedence is defined so that for
example "<" binds tighter than "and", would it work
for "char<?" also?  How about for my new defined
procedure that works on my type, "type<?"?  And
so on.

dwheeler actually made an attempt to support stuff
like arbitrary "type<?":