Swift style syntax
sphink at gmail.com
Tue Oct 13 16:34:26 UTC 2015
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:
> // Is this `x => f(x)` or `x = (>); f(x)`
> x =>
> // Is this `-x` or `-; 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:
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
More information about the es-discuss