Swift style syntax

Isiah Meadows isiahmeadows at gmail.com
Fri Oct 16 06:12:29 UTC 2015


I like the idea, but could the function names be made a little
shorter? I'd like to at least save some characters on it. Example:
`(a, b) => a > b` is 15 characters, where `Math.greaterThan` is 16.

For comparison, I also have equivalent versions for the colon-preceded operators

Here's some naming ideas I have:

Equality/Inequality:

- `a > b` -> `Math.gt` -> `:<`
- `a >= b` -> `Math.gte` -> `:<=`
- `a < b` -> `Math.lt` -> `:>`
- `a <= b` -> `Math.lte` -> `:>=`
- `a === b` -> Math.eq` -> `:===`
- `a !== b` -> `Math.neq` -> `:!==`
- `a == b` -> `Math.looseEq` -> `:==`
- `a != b` -> `Math.looseNeq` -> `:!=`

Basic Math:

- `a + b` -> `Math.add` -> `:+`
- `a - b` -> `Math.sub` -> `:-`
- `a * b` -> `Math.mul` -> `:*` (different from `imul`)
- `a / b` -> `Math.div` -> `:/`
- `a ** b` -> `Math.pow` -> `:**` (already exists)

- `+a` -> `Number(a)` (already exists)
- `-a` -> `Math.neg(a)`

Bitwise:

- `a & b` -> `Math.and` -> `:&`
- `a | b` -> `Math.or` -> `:|`
- `a ^ b` -> `Math.xor` -> `:^`
- `a << b` -> `Math.shl` -> `:<<`
- `a >> b` -> `Math.sar` -> `:>>`
- `a >>> b` -> `Math.shr` -> `:>>>`

- `~a` -> `Math.not(a)` -> `:~`

Logical:

- `a && b` -> `Math.land` -> `:&&`
- `a || b` -> `Math.lor` -> `:||`

- `!a` -> `Math.lnot` -> `:!`


Example:

```js
// A very inefficient, inaccurate N by N matrix multiplication implementation
const part = (f, x) => y => f(x, y)

function mul1(a, b) {
    return a.map((arow, i) =>
        arow.map((ax, j) =>
            b[j].map(brow => brow[i])
                .map(part(:*, ax))
                .reduce(:+, 0)))
}

function mul2(a, b) {
    return a.map((arow, i) =>
        arow.map((ax, j) =>
            b[j].map(brow => brow[i])
                .map(part(Math.mul, ax))
                .reduce(Math.add, 0)))
}
```

What do you all think?

On Thu, Oct 15, 2015 at 7:53 PM, Viktor Kronvall
<viktor.kronvall at gmail.com> wrote:
>> but I'd vote for `Math.greaterThan`
>
> I agree with this. This solution also disambiguates negate and minus which
> is good. If we were to introduce operators as functions with syntax I would
> prefer if there was some syntax to know if the operator was a binary or
> unary function.
>
> Regarding operators how does this proposal interact with the proposal for
> value types and operator overloading?
>
> 2015-10-15 23:08 GMT+02:00 Michael McGlothlin <mike.mcglothlin at gmail.com>:
>>
>> It'd be simple to just define all operators as functions and the actual
>> operator is just syntaxial sugar. And then if you wanted to pass the
>> operator you'd simply pass it's function around like you would any other
>> function. Even your `Math.['>']` seems far safer than `Math.>` or just `>`
>> but I'd vote for `Math.greaterThan` as being the best name. Saving a couple
>> letters of typing isn't worth the price of hours more debugging.
>>
>> _______________________________________________
>> 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
>



-- 
Isiah Meadows


More information about the es-discuss mailing list