value proxies, fundamental traps for binary operators, precedence
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:
- 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:
strawman:value_types, strawman:value_proxies
hint at this. More work needed.
- 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!
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?
- 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.
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:
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)
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] strawman:value_proxies
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