Hi Claus, Interesting idea; I'd never considered lifting some of these good syntax ideas from Haskell before.
One issue with the Haskell `...` syntax directly is conflict with the quasi-literals proposal, but we can think about alternatives offline (let's *not* get into a discussion of concrete syntax here on the list -- those never go well here). Also, in principle I like the idea of borrowing Haskell's partial operator application syntax, but it doesn't work with operators like + and -, since those are also already valid unary prefix operators. We could think about a somewhat more explicit syntax, where you could represent partial operator application with some explicit token representing a curried argument position. But then this wouldn't be quite as lightweight and lovely as Haskell's syntax, and it would require stealing another ASCII special character, and at that point it's not sure whether the benefit would outweigh the cost. But speaking for myself anyway, I'll chew on the idea. Thanks for bringing it up! Best, Dave On Mar 24, 2011, at 11:11 AM, Claus Reinke wrote: >> Infix operators: >> has, mod, div, min, max > > Is there someplace where one could look up what alternative > design options were considered and discarded for Ecmascript > in the past? > > It strikes me as odd to see specific infix operators hardcoded > in the language spec. The discussion notes (repeated below) > confirm that this is a risky approach, but it is also a limiting > approach (you can't have every application domain lobbying > the language committee for new infix operators). > I'd be interested to learn whether user-defined infix operators have been > considered, to keep the language-level specification limited but general, > while allowing late specification of details in library code. > > For comparison, Haskell has taken a simplistic, but usually > good enough approach, permitting simple forms of user- > defined infix operators, thereby keeping operator-specific > decisions out of the language spec (these become a library responsibility, > and libraries tend to be easier to change - > at least, alternative definitions can be provided if the > standard library operator definitions turn out to be flawed, > and new applications aren't dependent on language evolution): > > - no a priori distinction between infix and other functions > > - rule of thumb: - symbolic names indicate infix, - non-symbolic names > indicate prefix > - support for conversion betwen infix and prefix: > - (+) turns infix op + into prefix function > - `f` turns prefix function f into infix operator > > - operator precedence and associativity can be defined > for both synbolic and backquoted operators > > There are more details, e.g., indicating constructors, or permitting > "sections" (a section is an infix operator, partially applied to one of its > arguments, such as (1/) or (/2); with no general support for partial > application in Javascript, operator sections seem not applicable here, but > they are handy for higher-order functions, such as map, filter, ..). > > So you can write "(3 `div` 2)", or "map (+1) [1,2,3]". Without operator > sections, "map (+1)" would become "map (\x->x+1)". > > And all of that is defined in libraries, so if users want to > define addition over arrays or matrices, or new infix operators > for dealing with asynchronous code and callbacks, they can > (similarly, if they want alternative operators with reversed > order of arguments, or if the standard behaviour is inadequate for their > application domain). > > Limitations have been discussed, too (there are ten fixed > operator precedence levels, where some would prefer > relative operator precedences, or at least more levels). On the whole, the > system has proven to be quite useable. > > Claus > "Give a man an infix operator and you feed him for a day. Teach a man to make > infix operators and you feed him for a lifetime" > > PS. I hope it is okay to contrast Ecmascript design questions > against Haskell's here? > >> Syntax is compatible with ES5 (as long as there is a [no linebreak >> here] before the keyword) but precludes some considered extensions >> such as attributes decorating definitions. >> Debate about reverse direction of "has" vs. "in". >> Brendan: Not clear if "has" is worth it. >> "mod" produces the same sign as the divisor (as opposed to %, which >> produces the same sign as the dividend). >> How is "div" different from a division followed by truncation towards >> zero? They're almost the same, but the intermediate division can >> round up to the next integer if it's within 1/2 ulp of an integer, >> while div wouldn't. >> Brendan: Sympathetic to "mod" and "div" because the versions that >> people should use are obscure or wordy. >> Why not ** for power? >> "min" and "max" feel weird as infix operators. > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
