Swift style syntax

Isiah Meadows isiahmeadows at gmail.com
Sun Oct 18 04:20:19 UTC 2015


A standard module library is something I've been wanting in ECMAScript
proper for a while, now. It doesn't necessarily have to be in ECMA-262
itself, but it would be nice to have somewhere. It's come up several
times already in this list, even as far back as 2012, when the module
with syntax concept was first thought of. It's just a fantasy that
hasn't been realized yet. It would make new features a little easier
to add, though, and I would actually rate a standard module
implementation a little higher in importance than most of the more
recent ideas, in my personal opinion.

On Sat, Oct 17, 2015 at 12:24 AM, Bob Myers <rtm at gol.com> wrote:
> What has been the discussion if any about having "standard" libraries, with
> well-defined behavior and included in the engine, but which must be imported
> to use to avoid collisions and backward incompatibility? In theory the
> import could also result in new methods on standard prototypes.  Eg
>
> ```js
> import 'std::Functional';
> var _add = ((a, b) => a + b).currify();
>
> import * as Fn from 'std::Functional';
> var _add = Fn.currify((a, b) => a + b));
>
> import currify from 'std::Functional';
> var _add = currify((a, b) => a + b));
> ```
>
> This approach could also possibly be used for `Op`.
>
> --
> Bob
>
> On Sat, Oct 17, 2015 at 2:17 AM, Michael McGlothlin
> <mike.mcglothlin at gmail.com> wrote:
>>
>> Having Op for all operator functions would be a good call. Probably better
>> than adding Bitwise, Logic, etc just from the point of view of not filling
>> up the namespace to much. I think short names would be fine so long as they
>> were readable. So leftShift could be lShift but lsh is probably to
>> mysterious. Even operator-like functions without an actual operator assigned
>> would make sense I think so no reason not to include pow. A general purpose
>> casting operator/func would be good I think but not sure if there is a point
>> to specialized ones just to numbers, strings, and whatnot.
>>
>> On Fri, Oct 16, 2015 at 2:39 PM, Isiah Meadows <isiahmeadows at gmail.com>
>> wrote:
>>>
>>> That might work, although these two might need edited for consistency:
>>>
>>> - Math.pow === Op.pow (assuming `**` gets in)
>>> - Op.num should be similar to `x => +x`, not `x => ToNumber(x)`. The
>>> behavior is slightly different, but can be observable without modifying
>>> `Number`, I believe.
>>>
>>>
>>> On Fri, Oct 16, 2015, 14:43 Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>>>>
>>>> On Thu, Oct 15, 2015 at 11:12 PM, Isiah Meadows <isiahmeadows at gmail.com>
>>>> wrote:
>>>> > 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:
>>>> [snip]
>>>>
>>>> At that point, though, the use of the Math namespace starts getting
>>>> weird.  Equality and Logical aren't mathematical; Bitwise mostly isn't
>>>> either.  (It can sometimes be used to do mathy things, like using
>>>> shift to mul/div by a power of 2, but that's not its core purpose.)
>>>>
>>>> Put them on a new Op namespace object, or into an Op built-in module.
>>>> Even shorter, and clearer!
>>>>
>>>> ~TJ
>>>
>>>
>>> _______________________________________________
>>> 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