Novel operator syntax
On Tue, Oct 29, 2013 at 10:01 AM, Tristan Zajonc <tristan at senseplatform.com> wrote:
- What would be the most likely syntax? As a reference, Julia and Matlab use dots, a .+ b. Stata's Mata languages uses colons, a :+ b. PEP225 proposes tildle a ~+ b. R uses %infix% but this is widely viewed as a bad choice. The technical community would prefer dots. I know these prefixes all having meanings alone, but does .op introduce any ambiguity? Are there other lightweight options?
Yes, .op is completely unusable. "foo .bar" is identical to "foo.bar".
On Tue, Oct 29, 2013 at 10:37 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
Yes, .op is completely unusable. "foo .bar" is identical to "foo.bar".
Sorry, at most I'm only proposing every existing operator prefixed by ., not new operators. So things like .+, ./, .*, .-., .%, .==, .!=, .>, .<, etc. These would be called dot operators. This is all that's required by the technical computing use case.
There's a question of whether to allow arbitrary operators, which would require a new symbol obviously. I personally don't think arbitrary operators are worth the noise and complexity. I'd leave this issue to macros.
Tristan Zajonc wrote:
Sorry, at most I'm only proposing every existing operator prefixed by ., not new operators. So things like .+, ./, .*, .-., .%, .==, .!=, .>, .<, etc. These would be called dot operators. This is all that's required by the technical computing use case.
Why is the dot needed, though?
The PEP Tristan posted offers a pretty compelling case for distinguishing elementwise operators from objectwise ones (although not for this dot syntax per se, they went with a ~-prefix): www.python.org/dev/peps/pep-0225
Dean Landolt wrote:
The PEP Tristan posted offers a pretty compelling case for distinguishing elementwise operators from objectwise ones (although not for this dot syntax per se, they went with a ~-prefix): www.python.org/dev/peps/pep-0225
Got it, thanks. We could indeed do .+, .*, etc. without ambiguity. (Ignore E4X's wildcards: xml.* etc.!)
Got it, thanks. We could indeed do .+, .*, etc. without ambiguity. (Ignore E4X's wildcards: xml.* etc.!)
No. ;-)
js> 1.*2
2
Right you are. That was the same issue with Python. Are there any blockers to ~*?
On 10/29/2013 7:51 PM, Tristan Zajonc wrote:
Right you are. That was the same issue with Python. Are there any blockers to ~*?
There are the usual ASI problems. For example this is currently valid:
a
~+ b
It is parsed as:
a;
~+ b;
André Bargull wrote:
There are the usual ASI problems.
The fix we entertained for 'is' and 'isnt' was restricted productions:
AdditiveExpression [no LineTerminator here] '~+' MultiplicativeExpression
But we lose backward compatibility. Probably survivable, but who knows? See my recent post replying to Brandon Andrews.
Note this means ~+ cannot be a single lexeme in general. It has to be two, ~ and +, when used in the unlikely way: as unary prefix operators composed together.
What about +:? This actually has some visual appeal if primary motivation is elementwise operations and is a syntax error with that ASI example. The downside is that it can end up pretty close to existing syntax like {a+:1} vs. {a:+1}, although I don't expect that to be a common use.
Tristan Zajonc wrote:
What about +:? This actually has some visual appeal if primary motivation is elementwise operations and is a syntax error with that ASI example. The downside is that it can end up pretty close to existing syntax like {a+:1} vs. {a:+1}, although I don't expect that to be a common use.
Yeah, that could work. We're unlikely to use : as a prefix operator due to ?:, and even less likely (as in 0) as an infix operator (note: not type annotation separator in declarations) due to labels.
I would love to have a way to write function calls infix. That may cover your use case as well. That is (strawman syntax):
arg1 #func arg2
would be syntactic sugar for
func(arg1, arg2)
Advantages: more versatile, less grawlixy. Problem: would make much more sense with multiple dispatch (dynamic dispatch over the arguments), but that doesn’t seem to be in the cards for JavaScript.
Axel Rauschmayer wrote:
Advantages: more versatile, less grawlixy.
# is pure grawlix. It's also one of the few ASCII punctuators left, so wanted otherwise.
Problem: would make much more sense with multiple dispatch (dynamic dispatch over the arguments), but that doesn’t seem to be in the cards for JavaScript.
The operators stuff I've been developing uses a variant of multimethod dispatch.
Operators cannot be usable if spelled #add, so we must support all the built-in ones I've talked about (see www.slideshare.net/BrendanEich/js-resp). Whether we need element-wise operators is really what this thread is about (I think, based on Tristan's spinout). Arbitrary infix named operators IMHO want another thread, and also later. Design means leaving things out (N. Wirth).
Brendan Eich wrote:
Tristan Zajonc wrote:
What about +:? This actually has some visual appeal if primary motivation is elementwise operations and is a syntax error with that ASI example. The downside is that it can end up pretty close to existing syntax like {a+:1} vs. {a:+1}, although I don't expect that to be a common use.
Yeah, that could work. We're unlikely to use : as a prefix operator due to ?:, and even less likely (as in 0) as an infix operator (note: not type annotation separator in declarations) due to labels.
Warming up to +:, *:, etc. Thanks for this suggestion!
On Tue, Oct 29, 2013 at 3:03 PM, Brendan Eich <brendan at mozilla.com> wrote:
The operators stuff I've been developing uses a variant of multimethod dispatch.
Operators cannot be usable if spelled #add, so we must support all the built-in ones I've talked about (see www.slideshare.net/BrendanEich/js-resp). Whether we need element-wise operators is really what this thread is about (I think, based on Tristan's spinout). Arbitrary infix named operators IMHO want another thread, and also later. Design means leaving things out (N. Wirth).
Both operators and element-wise operators really benefit from Brendan's multiple dispatch proposal. Julia has used this approach to great effect. I'm not opposed to it, but I don't believe there's a compelling need for arbitrary infix operators in the technical computing domain. The motivation for elementwise operators is to allow for a clean matrix API that would make JS best-of-bread for numerical computing. A secondary benefit is that it could provide a cow path towards high performance BLAS backed matrix operations making it to the browser sometime far in the future. Any suitably lightweight syntax would work, although +: has some things to recommend it.
On Tue, Oct 29, 2013 at 4:51 PM, Tristan Zajonc <tristan at senseplatform.com> wrote:
Both operators and element-wise operators really benefit from Brendan's multiple dispatch proposal. Julia has used this approach to great effect. I'm not opposed to it, but I don't believe there's a compelling need for arbitrary infix operators in the technical computing domain.
Perhaps not in the technical computing domain, but Haskell's ability to turn any function into an infix operator is pretty nice, and occasionally makes things much easier to read/write as DSLs. (As is the opposite - the ability to turn an operator into a function, perhaps partially applied.)
Following up on the discussion about operator overloading, what are viable options for introducing novel infix operators or a class of extended/prefixed operators?
For motivation, I along with some others have implemented a MATLAB/R like environment for JS. We've written a compile-to-js language that supports, among other things, operator overloading and prefixed operators, However we'd much prefer to follow ES6/7 and ideally avoid the need for a compile-to-js language entirely, at least in the future. Without going into the details, prefixed operators are useful for defining objectwise and elementwise operations on matrices, which is a core type in technical computing (see Julia, MATLAB, Mata, Python PEP 225).
Assuming JS allowed prefixed operators:
What would be the most likely syntax? As a reference, Julia and Matlab use dots, a .+ b. Stata's Mata languages uses colons, a :+ b. PEP225 proposes tildle a ~+ b. R uses %infix% but this is widely viewed as a bad choice. The technical community would prefer dots. I know these prefixes all having meanings alone, but does .op introduce any ambiguity? Are there other lightweight options?
Is there a preferred class literal syntax? I believe the proposed value object syntax would be perfect if extended to classes as well.
Can this be done prior to macros? It may be my narrow matrix centered view, but I do not believe there's a compelling need for arbitrary infix operators in technical computing if it introduces additional difficulties.
With ES6 and these operators I believe JS/NodeJS could easily take over the technical and statistical computing domains.