
12

Is it possible to extend JavaScript syntax to support Swift style block syntax[1]?
In Swift it's possible to omit return keyword ``` reversed = names.sort( { s1, s2 in s1 > s2 } )
```
or omit argument declaration like this:
``` reversed = names.sort( { $0 > $1 } )
```
or apply an operator to arguments of a function
``` ``` We have the first feature in ES2015 already:
``` let sorted = names.sort((a, b)=> a > b); ```
But for omitting argument declaration we need to find an alternative to $0, $1... since those are valid variable names in JS. Maybe we can use #0, #1... instead.
This is very useful for functional programming aspect of JS. For example in a filter function:
``` let passed = objs.filter(#0.passed) ```
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


IMO this is a good idea. When it's abundantly clear from context, I've already been naming my arrow function params _ if singular, and _1, _2 etc if several. As always, picking some punctuation straight from the scarce and sacred set of remaining ASCII symbols is going to be tricky. (If only we could just go APL on this!)
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


In the case of sorting, are arrow functions not good enough? Or are we really asking for full continuation support IMO this is a good idea. When it's abundantly clear from context, I've already been naming my arrow function params _ if singular, and _1, _2 etc if several. As always, picking some punctuation straight from the scarce and sacred set of remaining ASCII symbols is going to be tricky. (If only we could just go APL on this!)
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


> Le 11 oct. 2015 à 17:45, Mohsen Azimi < [hidden email]> a écrit :
>
>
> But for omitting argument declaration we need to find an alternative to $0, $1... since those are valid variable names in JS. Maybe we can use #0, #1... instead.
>
> This is very useful for functional programming aspect of JS. For example in a filter function:
>
> ```
> let passed = objs.filter(#0.passed)
> ```
Your syntax is ambiguous: Should your code be interpreted as:
let passed = objs.filter($0 => $0.passed)
or:
let passed = $0 => objs.filter($0.passed)
You need some syntax in order to delimitate the function.
—Claude
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


I don't think there's much value in this. Also sort is a bad example because it'd look like this, and there's no nifty shortcut answer to it.
```js names.sort((a, b) => a < b ? 1 : a > b ? 1 : 0);
```
In most cases you save a couple characters, but you can just use x/y/a/b/f/g/n/xs/xss for variable names in arrow functions instead of the $0 (which would likely be \0 in js).
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


> Your syntax is ambiguous: Should your code be interpreted as: > > let passed = objs.filter($0 => $0.passed) > > or: > > let passed = $0 => objs.filter($0.passed)
I don't understand why you parsed it in the second way Claude?
A more real world like example would be this:
``` let chbx = Array.from(document.querySelectorAll('input[type="checkbox"]'));
let checkedBoxes = chbx.filter(#0.checked) ```
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


On Mon, Oct 12, 2015 at 10:12 AM, Mohsen Azimi < [hidden email]> wrote:
>> Your syntax is ambiguous: Should your code be interpreted as:
>>
>> let passed = objs.filter($0 => $0.passed)
>>
>> or:
>>
>> let passed = $0 => objs.filter($0.passed)
>
> I don't understand why you parsed it in the second way Claude?
It's not about the "why". He's trying to tell you this code _is_
ambiguous. The parser cares not about the why.
Look at the generic case; how could the parser know how `#0` is scoped?
There is an ambiguity and you'll need some way of telling JS what the
scope is of that `#0`. This is why there's an arrow. This is why you
need to wrap arguments in parenthesis: Disambiguation. Basically; try
to think of ways how your example should be translated. Then try to
see if they _can_ be translated differently. If they can, then you
need to think of a way to disambiguate. In the above, having no
"function offset marker" (like what the arrow is) means you cannot
know where it starts.
On a personal two cents; ugh, changes in this proposal would only lead
to even worse illegible code.
 peter
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


Is it possible to extend JavaScript syntax to support Swift style block syntax[1]?
In Swift it's possible to omit return keyword ``` reversed = names.sort( { s1, s2 in s1 > s2 } )
```
As you note below this is already possible in es6, and might I add, has much more intuitive syntax in Es6. The swift syntax looks like a list comprehension gone wrong. or omit argument declaration like this:
``` reversed = names.sort( { $0 > $1 } )
```
I for one think this is a bad idea  use rest arguments instead. It's pretty terrible as far as readability goes, although I'd like to see more examples of it being used in Swift code. or apply an operator to arguments of a function
``` ```
This might actually be possible  I can't think of any ambiguous situations for passing operators as if they were first class functions. If it is possible, I'd like to see this done. We have the first feature in ES2015 already:
``` let sorted = names.sort((a, b)=> a > b); ```
But for omitting argument declaration we need to find an alternative to $0, $1... since those are valid variable names in JS. Maybe we can use #0, #1... instead.
This is very useful for functional programming aspect of JS. For example in a filter function:
``` let passed = objs.filter(#0.passed) ```
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


for "historical record" sake that silly trick works even in a more meaningful way with RegExp replacements :)
```js // before 'str'.replace(/(some)(thing)/, function ($0, $1, $2) { // boring $1 $2 like RegExp.$1 and RegExp.$2 });
// now 'str'.replace(/(some)(thing)/, (...$) => { // we have $[1], $[2] ... yaiiii }); ```
Regards
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


> reversed = names.sort(>) > This might actually be possible  I can't think of any ambiguous situations for passing operators as if they were first class functions. If it is possible, I'd like to see this done.
Yes, it would be really cool if operators can be used as function. For example in Swift you can do this:
``` let scores = [10, 13, 15, 8, 9, 19, 20, 4, 6];
let sum = scores.reduce(0, combine: +) // 104 ```
Or this:
``` var bools = [true, false, false, true, true];
bools.filter(!) // [false, false] ```
On Mon, Oct 12, 2015 at 7:29 AM Andrea Giammarchi < [hidden email]> wrote: for "historical record" sake that silly trick works even in a more meaningful way with RegExp replacements :)
```js // before 'str'.replace(/(some)(thing)/, function ($0, $1, $2) { // boring $1 $2 like RegExp.$1 and RegExp.$2 });
// now 'str'.replace(/(some)(thing)/, (...$) => { // we have $[1], $[2] ... yaiiii }); ```
Regards
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


For that, the question would arise: is `scores.reduce((a, b) => a + b)` and `bools.filter(x => !x)` so troublesome to write that it's worth the added complexity to the language? "it would be nice" generally doesn't outweigh increased implementation and maintenance cost to implementors, learners, tool creators, etc.
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


Operator.plus? I'd be totally ok with that. On Monday, 12 October 2015, Jordan Harband < [hidden email]> wrote: For that, the question would arise: is `scores.reduce((a, b) => a + b)` and `bools.filter(x => !x)` so troublesome to write that it's worth the added complexity to the language? "it would be nice" generally doesn't outweigh increased implementation and maintenance cost to implementors, learners, tool creators, etc.
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


+1 for operators as functions (I frequently is them in languages that have them), but there is an ambiguous case that frequently gets me: does `()` represent subtraction or negation. It's usually the former in languages with operators as functions.
But here's a couple other potential syntactical ambiguities, dealing with ASI:
```js
// Is this `x => f(x)` or `x = (>); f(x)`
x =>
f(x)
// Is this `x` or `; x`?

x
```
Those can be addressed with a cover production to be used for expression statements and direct value assignment, requiring parentheses to clarify the latter case in each.
A similar ambiguity problem, arguably harder to resolve, is partially applied subtraction, such as `( 2)`. Is that a 2 or is it equivalent to `x => x  2`? I will caution on this idea, as I know that's the next logical step.
Is it possible to extend JavaScript syntax to support Swift style block syntax[1]?
In Swift it's possible to omit return keyword ``` reversed = names.sort( { s1, s2 in s1 > s2 } )
```
As you note below this is already possible in es6, and might I add, has much more intuitive syntax in Es6. The swift syntax looks like a list comprehension gone wrong. or omit argument declaration like this:
``` reversed = names.sort( { $0 > $1 } )
```
I for one think this is a bad idea  use rest arguments instead. It's pretty terrible as far as readability goes, although I'd like to see more examples of it being used in Swift code. or apply an operator to arguments of a function
``` ```
This might actually be possible  I can't think of any ambiguous situations for passing operators as if they were first class functions. If it is possible, I'd like to see this done. We have the first feature in ES2015 already:
``` let sorted = names.sort((a, b)=> a > b); ```
But for omitting argument declaration we need to find an alternative to $0, $1... since those are valid variable names in JS. Maybe we can use #0, #1... instead.
This is very useful for functional programming aspect of JS. For example in a filter function:
``` let passed = objs.filter(#0.passed) ```
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


All this is wellknown from functional languages, with wellknown
solutions. The only real problem is:
let f = ()
Is this unary or binary ``?
On 13 October 2015 at 08:06, Isiah Meadows < [hidden email]> wrote:
> +1 for operators as functions (I frequently is them in languages that have
> them), but there is an ambiguous case that frequently gets me: does `()`
> represent subtraction or negation. It's usually the former in languages with
> operators as functions.
>
> But here's a couple other potential syntactical ambiguities, dealing with
> ASI:
>
> ```js
> // Is this `x => f(x)` or `x = (>); f(x)`
> x =>
> f(x)
>
> // Is this `x` or `; x`?
> 
> x
> ```
>
> Those can be addressed with a cover production to be used for expression
> statements and direct value assignment, requiring parentheses to clarify the
> latter case in each.
>
> A similar ambiguity problem, arguably harder to resolve, is partially
> applied subtraction, such as `( 2)`. Is that a 2 or is it equivalent to `x
> => x  2`? I will caution on this idea, as I know that's the next logical
> step.
>
>
> On Mon, Oct 12, 2015, 06:43 Thomas < [hidden email]> wrote:
>>
>>
>> Is it possible to extend JavaScript syntax to support Swift style block
>> syntax[1]?
>>
>> In Swift it's possible to omit return keyword
>> ```
>>
>> reversed = names.sort( { s1, s2 in s1 > s2 } )
>>
>> ```
>>
>>
>> As you note below this is already possible in es6, and might I add, has
>> much more intuitive syntax in Es6. The swift syntax looks like a list
>> comprehension gone wrong.
>>
>> or omit argument declaration like this:
>>
>> ```
>>
>> reversed = names.sort( { $0 > $1 } )
>>
>> ```
>>
>>
>> I for one think this is a bad idea  use rest arguments instead. It's
>> pretty terrible as far as readability goes, although I'd like to see more
>> examples of it being used in Swift code.
>>
>> or apply an operator to arguments of a function
>>
>> ```
>>
>> reversed = names.sort(>)
>>
>> ```
>>
>>
>> This might actually be possible  I can't think of any ambiguous
>> situations for passing operators as if they were first class functions. If
>> it is possible, I'd like to see this done.
>>
>> We have the first feature in ES2015 already:
>>
>> ```
>> let sorted = names.sort((a, b)=> a > b);
>> ```
>>
>> But for omitting argument declaration we need to find an alternative to
>> $0, $1... since those are valid variable names in JS. Maybe we can use #0,
>> #1... instead.
>>
>> This is very useful for functional programming aspect of JS. For example
>> in a filter function:
>>
>> ```
>> let passed = objs.filter(#0.passed)
>> ```
>>
>>
>> [1][ https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Closures.html]
>>
>> _______________________________________________
>> esdiscuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/esdiscuss>>
>> _______________________________________________
>> esdiscuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/esdiscuss>
>
> _______________________________________________
> esdiscuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/esdiscuss>
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


I failed to mention that clearly enough... In most functional languages, that's binary. And I think that should be the same for JS. It's surprising otherwise.
I'd say the closest precedent here I know of would be LiveScript, where the operator is treated as binary when used as a function. Most functional languages have separate functions for subtraction and negation, including Haskell (`` vs `negate`) and OCaml (`` and `.` vs `negate` and `fnegate`).
All this is wellknown from functional languages, with wellknown
solutions. The only real problem is:
let f = ()
Is this unary or binary ``?
On 13 October 2015 at 08:06, Isiah Meadows <[hidden email]> wrote:
> +1 for operators as functions (I frequently is them in languages that have
> them), but there is an ambiguous case that frequently gets me: does `()`
> represent subtraction or negation. It's usually the former in languages with
> operators as functions.
>
> But here's a couple other potential syntactical ambiguities, dealing with
> ASI:
>
> ```js
> // Is this `x => f(x)` or `x = (>); f(x)`
> x =>
> f(x)
>
> // Is this `x` or `; x`?
> 
> x
> ```
>
> Those can be addressed with a cover production to be used for expression
> statements and direct value assignment, requiring parentheses to clarify the
> latter case in each.
>
> A similar ambiguity problem, arguably harder to resolve, is partially
> applied subtraction, such as `( 2)`. Is that a 2 or is it equivalent to `x
> => x  2`? I will caution on this idea, as I know that's the next logical
> step.
>
>
> On Mon, Oct 12, 2015, 06:43 Thomas <[hidden email]> wrote:
>>
>>
>> Is it possible to extend JavaScript syntax to support Swift style block
>> syntax[1]?
>>
>> In Swift it's possible to omit return keyword
>> ```
>>
>> reversed = names.sort( { s1, s2 in s1 > s2 } )
>>
>> ```
>>
>>
>> As you note below this is already possible in es6, and might I add, has
>> much more intuitive syntax in Es6. The swift syntax looks like a list
>> comprehension gone wrong.
>>
>> or omit argument declaration like this:
>>
>> ```
>>
>> reversed = names.sort( { $0 > $1 } )
>>
>> ```
>>
>>
>> I for one think this is a bad idea  use rest arguments instead. It's
>> pretty terrible as far as readability goes, although I'd like to see more
>> examples of it being used in Swift code.
>>
>> or apply an operator to arguments of a function
>>
>> ```
>>
>> reversed = names.sort(>)
>>
>> ```
>>
>>
>> This might actually be possible  I can't think of any ambiguous
>> situations for passing operators as if they were first class functions. If
>> it is possible, I'd like to see this done.
>>
>> We have the first feature in ES2015 already:
>>
>> ```
>> let sorted = names.sort((a, b)=> a > b);
>> ```
>>
>> But for omitting argument declaration we need to find an alternative to
>> $0, $1... since those are valid variable names in JS. Maybe we can use #0,
>> #1... instead.
>>
>> This is very useful for functional programming aspect of JS. For example
>> in a filter function:
>>
>> ```
>> let passed = objs.filter(#0.passed)
>> ```
>>
>>
>> [1][https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Closures.html]
>>
>> _______________________________________________
>> esdiscuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/esdiscuss
>>
>> _______________________________________________
>> esdiscuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/esdiscuss
>
>
> _______________________________________________
> esdiscuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/esdiscuss
>
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


On 10/12/2015 11:06 PM, Isiah Meadows wrote:
>
> +1 for operators as functions (I frequently is them in languages that
> have them), but there is an ambiguous case that frequently gets me:
> does `()` represent subtraction or negation. It's usually the former
> in languages with operators as functions.
>
> But here's a couple other potential syntactical ambiguities, dealing
> with ASI:
>
> ```js
> // Is this `x => f(x)` or `x = (>); f(x)`
> x =>
> f(x)
>
> // Is this `x` or `; x`?
> 
> x
> ```
>
> Those can be addressed with a cover production to be used for
> expression statements and direct value assignment, requiring
> parentheses to clarify the latter case in each.
>
> A similar ambiguity problem, arguably harder to resolve, is partially
> applied subtraction, such as `( 2)`. Is that a 2 or is it equivalent
> to `x => x  2`? I will caution on this idea, as I know that's the
> next logical step.
>
It it just me? I find all this talk of bare operators to be
completely... uh, I'll go with "inadvisable".
I can believe that you could carve out an unambiguous path through the
grammar. But (a) it's going the way of line noise, (b) it uses up lots
of possibilities for future expansion on something that isn't all that
useful in the first place, and (c) it seems to be choosing concise
syntax over readability in a big way.
C++ has an 'operator' keyword (and even then it comes out pretty ugly 
operator()(), anyone?) Perl6 has better syntax (syntax syntax?) for this:
infix:<+>
circumfix:«( )»
or whatever. And of course Python uses double __underscores__ with ASCII
operator names. All those are preferable to bare operators, to me.
compose(+, *)(++x, +(3, 4), y)  (3 + 4)  (1, 2);
I don't really *want* that to parse! At least make it
list.sort(#`>`);
or something.
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


Steve, I have little problem with whatever ends up the case, as long as it's shorter than `(x, y) => x + y`. The current idea was inspired by Swift's `list.sort(>)` and `list.reduce(0, +)`.
On 10/12/2015 11:06 PM, Isiah Meadows wrote:
>
> +1 for operators as functions (I frequently is them in languages that
> have them), but there is an ambiguous case that frequently gets me:
> does `()` represent subtraction or negation. It's usually the former
> in languages with operators as functions.
>
> But here's a couple other potential syntactical ambiguities, dealing
> with ASI:
>
> ```js
> // Is this `x => f(x)` or `x = (>); f(x)`
> x =>
> f(x)
>
> // Is this `x` or `; x`?
> 
> x
> ```
>
> Those can be addressed with a cover production to be used for
> expression statements and direct value assignment, requiring
> parentheses to clarify the latter case in each.
>
> A similar ambiguity problem, arguably harder to resolve, is partially
> applied subtraction, such as `( 2)`. Is that a 2 or is it equivalent
> to `x => x  2`? I will caution on this idea, as I know that's the
> next logical step.
>
It it just me? I find all this talk of bare operators to be
completely... uh, I'll go with "inadvisable".
I can believe that you could carve out an unambiguous path through the
grammar. But (a) it's going the way of line noise, (b) it uses up lots
of possibilities for future expansion on something that isn't all that
useful in the first place, and (c) it seems to be choosing concise
syntax over readability in a big way.
C++ has an 'operator' keyword (and even then it comes out pretty ugly 
operator()(), anyone?) Perl6 has better syntax (syntax syntax?) for this:
infix:<+>
circumfix:«( )»
or whatever. And of course Python uses double __underscores__ with ASCII
operator names. All those are preferable to bare operators, to me.
compose(+, *)(++x, +(3, 4), y)  (3 + 4)  (1, 2);
I don't really *want* that to parse! At least make it
list.sort(#`>`);
or something.
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


Isiah,
In Swift it's not allowed to assign an operator so the ambiguous case you brought up can be avoided by not allowing assigning operators.
``` let x = +; // not allowed ```
Or it's not allowed to store operators in dictionaries:
``` ``` The only place (as far as I know) you can pass operators as functions is in arguments list of a function call. I don't know why but it doesn't work with unary operators either: ``` let nums = [1,3,4];
numsnums.map(++) // error ``` On Tue, Oct 13, 2015 at 10:27 AM Isiah Meadows < [hidden email]> wrote: Steve, I have little problem with whatever ends up the case, as long as it's shorter than `(x, y) => x + y`. The current idea was inspired by Swift's `list.sort(>)` and `list.reduce(0, +)`.
On 10/12/2015 11:06 PM, Isiah Meadows wrote:
>
> +1 for operators as functions (I frequently is them in languages that
> have them), but there is an ambiguous case that frequently gets me:
> does `()` represent subtraction or negation. It's usually the former
> in languages with operators as functions.
>
> But here's a couple other potential syntactical ambiguities, dealing
> with ASI:
>
> ```js
> // Is this `x => f(x)` or `x = (>); f(x)`
> x =>
> f(x)
>
> // Is this `x` or `; x`?
> 
> x
> ```
>
> Those can be addressed with a cover production to be used for
> expression statements and direct value assignment, requiring
> parentheses to clarify the latter case in each.
>
> A similar ambiguity problem, arguably harder to resolve, is partially
> applied subtraction, such as `( 2)`. Is that a 2 or is it equivalent
> to `x => x  2`? I will caution on this idea, as I know that's the
> next logical step.
>
It it just me? I find all this talk of bare operators to be
completely... uh, I'll go with "inadvisable".
I can believe that you could carve out an unambiguous path through the
grammar. But (a) it's going the way of line noise, (b) it uses up lots
of possibilities for future expansion on something that isn't all that
useful in the first place, and (c) it seems to be choosing concise
syntax over readability in a big way.
C++ has an 'operator' keyword (and even then it comes out pretty ugly 
operator()(), anyone?) Perl6 has better syntax (syntax syntax?) for this:
infix:<+>
circumfix:«( )»
or whatever. And of course Python uses double __underscores__ with ASCII
operator names. All those are preferable to bare operators, to me.
compose(+, *)(++x, +(3, 4), y)  (3 + 4)  (1, 2);
I don't really *want* that to parse! At least make it
list.sort(#`>`);
or something.
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss

12
