Infix Operators (Re: March 22/23 notes)

Claus Reinke claus.reinke at
Thu Mar 24 11:11:52 PDT 2011

> 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.

"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.


More information about the es-discuss mailing list