value proxies, fundamental traps for binary operators, precedence

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

value proxies, fundamental traps for binary operators, precedence

Claus Reinke
I finally got a first look at the 'Virtual Values for Language
Extension' paper referred to in the value proxies strawman [1],
and suddenly find value proxies more interesting.

Somehow the term proxy never suggested to me that this
would allow for user-defined infix operators - perhaps a wiki
page named 'infix operators', listing relevant pages (value
proxies, modulo operator, operators/generic functions, ..)
might help. Generally, finding relevant information on the
wiki isn't straightforward for newcomers.

On to questions:

1. Are fundamental traps for binary operators in value proxies
    the only current candidate for user-defined infix operators?
    (currently, even this candidate isn't part of Harmony)

2. Do they make any provisions for specifying operator
    precedence/associativity?

It seems that the wiki page about value proxies is mostly
concerned with defining traps, less with other issues of use
(such as parsing: operator precedence, associativity).

Claus

[1] http://wiki.ecmascript.org/doku.php?id=strawman:value_proxies
 
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: value proxies, fundamental traps for binary operators, precedence

Brendan Eich-3
On Apr 8, 2011, at 11:29 AM, Claus Reinke wrote:

> I finally got a first look at the 'Virtual Values for Language Extension' paper referred to in the value proxies strawman [1],
> and suddenly find value proxies more interesting.
>
> Somehow the term proxy never suggested to me that this
> would allow for user-defined infix operators - perhaps a wiki
> page named 'infix operators', listing relevant pages (value
> proxies, modulo operator, operators/generic functions, ..)
> might help. Generally, finding relevant information on the wiki isn't straightforward for newcomers.

Good point, operators in particular need some navigational help. I'll do something about it.


> On to questions:
>
> 1. Are fundamental traps for binary operators in value proxies    the only current candidate for user-defined infix operators?
>   (currently, even this candidate isn't part of Harmony)

No, we've talked about operators for other types of objects too. The current value types strawmen:

http://wiki.ecmascript.org/doku.php?id=strawman:value_types
http://wiki.ecmascript.org/doku.php?id=strawman:value_proxies

hint at this. More work needed.


> 2. Do they make any provisions for specifying operator    precedence/associativity?

Certainly not. We are not trying to enable new operators to be defined. We are not trying to enable user-defined changes to the precedence, e.g., of * vs. +. These are anti-goals. Moreso (stronger anti-goal language) for associativity!

/be

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: value proxies, fundamental traps for binary operators, precedence

Claus Reinke
>> finding relevant information on the wiki isn't straightforward
>> for newcomers.
>
> Good point, operators in particular need some navigational
> help. I'll do something about it.

Thanks. Btw, other things I've been looking for are timeline,
process, committee information, and software information
(which JS-in-JS tools to use for prototyping language design
ideas). The meetings page could perhaps link to an archive
search for this mailing list, for the meeting notes?

>> 2. Do they make any provisions for specifying operator    
>> precedence/associativity?
>
> Certainly not. We are not trying to enable new operators to
> be defined. We are not trying to enable user-defined changes
> to the precedence, e.g., of * vs. +. These are anti-goals. Moreso
> (stronger anti-goal language) for associativity!

Ah, that explains it. But I'm sorry to hear this. I can understand
that redefining properties of standard operators is not something
you want (source of programmer confusion), but that concern
does not apply to defining new operators.

It is very strange for me to see specific operators hard-coded
in the language syntax, but that is less worrying than not being
able to define my own operators. There is just no way that the
language designers can foresee all possible application domains
or the operators that are useful for those.

Embedded domain-specific languages are a major program
design pattern, and library-defined operators are a small part
of making languages like Haskell so successful at that game.

Library-defined infix operators are also important for
extracting common programming patterns into reusable
libraries, without library users drowning in excessive syntax.

Many of the operators that are now "standard" in Haskell
practice belong to libraries that didn't exist when the core
language was specified. Not to mention the operators that
are "standard" in specific application domains.

The more programming languages are becoming foundations
on which to provide useful programming patterns, the more
important it becomes that core syntax does not get in the way.

I'm not sure why user-defined infix operators are such an
anti-goal for you? Perhaps because you have to cater for
such a wide range of programmers?

It may be helpful to keep in mind that programmers who
might have trouble with this concept need not use it directly,
but ruling it out completely deprives library authors of an
important tool for making their libraries more useable (and
library users have no more trouble using
standard-for-their-library infix operators than they have with
standard-for-their-language infix operators).

Claus

PS: If they cannot define new operators, library authors will
    be tempted to re-interpret the operators which they can
    redefine (witness the rise of $), but that won't give them
    the same range of operators, and it will be even more
    confusing to programmers if, say, '*' suddenly means
    sequential composition, instead of a new, dedicated
    operator being defined for that purpose.

 
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss