Swift style syntax
me at azimi.me
Tue Oct 13 17:47:50 UTC 2015
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 = [
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>
> 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:
>> 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
>> or something.
>> es-discuss mailing list
>> es-discuss at mozilla.org
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss