Swift style syntax

[Mohsen Azimi]

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:

```

let dic = [
  "add": +
];

```
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 <isiahmeadows at gmail.com>
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 Tue, Oct 13, 2015, 12:34 Steve Fink <sphink at gmail.com> wrote:
>
>> 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.
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151013/ac631966/attachment.html>