Curried functions

[Niloy Mondal]

It would be really cool to have syntax to curry functions built into the
languages. Something like...

```js
curry function add(a, b) {
return a + b;
}

add(2)(3); // 5
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Exporting Symbols

[Francisco Tolmasky]

Not sure if it isn’t the case, but it seems the only way to export symbols
right now is:

```js
export default { [Symbol(“something”)]: blah }
```

It would be nice if “symbol literals” could somehow be supported. In
particular, I can imagine this sort of thing becoming common:

export { “5.4” as Symbol(“version”) }

Or, even better (but harder since its now more expression):

import VersionSymbol from “symbols"
export { “5.4” as VersionSymbol }

I’m currently writing an API where there are expected methods stored in
symbols, but this forces exporting one default object instead of being able
to lay them out individual.

Thanks,

Francisco

-- 
Francisco Tolmasky
www.tolmasky.com
tolma...@gmail.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exporting Symbols

[Logan Smyth]

The main issue is that modules are statically analysable and
imports/exports are processed before the module executes, and the behavior
of a symbol is by definition a runtime thing. Until the code executes,
there would be no symbol object, and there would be no way to know what
thing was being imported imported / exported.

The primary benefit of symbols is that they are unique, and cannot collide
unless you have a reference to them. Module exports have full control over
their names and don't have the same collision issues that objects and
classes generally do. What is the benefit you are hoping to get from
exposing these values on symbols instead of string keys?



On Thu, Oct 15, 2015 at 12:14 AM, Francisco Tolmasky 
wrote:

> Not sure if it isn’t the case, but it seems the only way to export symbols
> right now is:
>
> ```js
> export default { [Symbol(“something”)]: blah }
> ```
>
> It would be nice if “symbol literals” could somehow be supported. In
> particular, I can imagine this sort of thing becoming common:
>
> export { “5.4” as Symbol(“version”) }
>
> Or, even better (but harder since its now more expression):
>
> import VersionSymbol from “symbols"
> export { “5.4” as VersionSymbol }
>
> I’m currently writing an API where there are expected methods stored in
> symbols, but this forces exporting one default object instead of being able
> to lay them out individual.
>
> Thanks,
>
> Francisco
>
> --
> Francisco Tolmasky
> www.tolmasky.com
> tolma...@gmail.com
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Import statements & destructuring

[PLIQUE Guillaume]

Considering the following file exporting a raw object:

```js
/* ./config.js */
const config = {
  api: {
port: 25,
host: 'localhost'
  }
};

export default config;
```

If another file wants to import this file in order to access the
api.host property, it could do it thusly:

```js
import config from './config';
console.log(config.api.host);

// or else (typically this is what one would expect when importing
some older modules through Babel)
// but I am not entirely sure this would work for real with ES2015
import {api} from './config';
console.log(api.host);
```

Therefore, wouldn't it be useful to be able to use destructuring
within import statement as you would with objects:

```js
import {api: {host}} from './config';
console.log(host);
```

I guess this does not work for static evaluation reasons but I just
want to be sure this is it or if there are more obvious/profound
reasons concerning modules' system, syntax or philosophy that prevent
this.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Swift style syntax

[Michael McGlothlin]

It'd be simple to just define all operators as function​s 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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Swift style syntax

[Yongxu Ren]

I vote for operator overloading!

I think this is probably going to be a good way to do it:
```
//in local scope
let operator(**) = (lhs,rhs) => Math.pow(lhs,rhs);

//class method
Complex.prototype.operator(+) = function(lhs,rhs){
  return new Complex(lhs.r+rhs.r,lhs.i+rhs.i);
}

//global, may not be an good idea
operator(+) = (lhs,rhs) => lhs*rhs;
```
//this will work for case above
names.sort(>)
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Swift style syntax

[Viktor Kronvall]

> 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 :

> It'd be simple to just define all operators as function​s 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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Curried functions

[Yongxu Ren]

Sorry I actually didn’t mean to use this for currying
```
const add = a => b => a + b;
```
This was directly copied from Mark's example, I was thinking about making the 
non-nested arrow functional.
My idea is if you define
```
const add = (a,b) => a + b;
```
you will be able to use either ```add(a,b)``` or ```add(a)(b)```___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Curried functions

[Jeremy Darling]

If I understand your question correctly, your asking if fat arrow functions
could be auto curried?  I think this would be great, but anything using
...rest arguments could never be curried without finalization.

On Thu, Oct 15, 2015 at 2:58 PM, Yongxu Ren  wrote:

> Sorry I actually didn’t mean to use this for currying
> ```
> const add = a => b => a + b;
> ```
> This was directly copied from Mark's example, I was thinking about making
> the non-nested arrow functional.
> My idea is if you define
> ```
> const add = (a,b) => a + b;
> ```
> you will be able to use either ```add(a,b)``` or ```add(a)(b)```
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Curried functions

[Yongxu Ren]

Jeremy,
I think you were talking about are cases like this:
```
let add = (x,y,...z) => x+y+Math.max(z);
```
Since rested argument always has to be the last parameter, I guess this 
should’t be a big problem if we can interpret this case as:

```
//regular function and the rested argument are not curried by default
let add = (x,y) => function(...z){
return x+y+Math.max(z);
};
```
As long as we express it consistently, this shouldn’t be a problem.

Also, I do not believe this will be a problem:

> Too late, ```add(a)``` already returns ```a + undefined```.

First, I do not think anyone will ever intended to write code like this,

Second, if someone accidentally returned a function instead of an object, or a 
different function, it should be very obvious and can be very easily debugged.

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Curried functions

[Waldemar Horwat]

On 10/15/2015 12:58, Yongxu Ren wrote:

Sorry I actually didn’t mean to use this for currying
```
const add = a => b => a + b;
```
This was directly copied from Mark's example, I was thinking about making the 
non-nested arrow functional.
My idea is if you define
```
const add = (a,b) => a + b;
```
you will be able to use either ```add(a,b)``` or ```add(a)(b)```


Alexander's point still stands.  This would break compatibility, which makes it 
a non-starter.  It also becomes dubious with variable numbers of parameters.

Waldemar

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exporting Symbols

[Rick Waldron]

The math.trunc part is completely irrelevant, leftover from fiddling
around—sorry for the noise!

On Thu, Oct 15, 2015 at 4:13 PM Rick Waldron  wrote:

> Symbol has built-in API for making Symbols available across all code
> realms:
>
> http://www.ecma-international.org/ecma-262/6.0/#sec-symbol.for
> http://www.ecma-international.org/ecma-262/6.0/#sec-symbol.keyfor
>
>
> You can create a generated key and export it, giving your consumers only
> the key, which they can then use to get the symbol.
>
>   // In module.js
>   let key = Math.trunc((Math.random() * 0x));
>   let sym = Symbol.for(key);
>   // use sym throughout the module code
>   export { key as features }
>
>   // In program.js
>   import { features } from "module";
>
>   console.log(features, Symbol.for(features));
>
>
> Rick
>
>
>
>
>
> On Thu, Oct 15, 2015 at 3:38 PM Alexander Jones  wrote:
>
>> Unless of course you needed to export a "features" AND support this magic
>> symbol.
>>
>> On Thursday, 15 October 2015, Ron Buckton 
>> wrote:
>>
>>> Wouldn’t this work?
>>>
>>>
>>>
>>> our-symbols.js:
>>>
>>> ```js
>>>
>>> export const SpecialSymbol = Symbol("SpecialSymbol");
>>>
>>> ```
>>>
>>>
>>>
>>> their-consumer.js
>>>
>>> ```js
>>>
>>> import { SpecialSymbol } from "our-symbols";
>>>
>>>
>>>
>>> export const features = {
>>>
>>> [SpecialSymbol]: true
>>>
>>> };
>>>
>>> ```
>>>
>>>
>>>
>>> our-features.js
>>>
>>> ```js
>>>
>>> import { SpecialSymbol } from "our-symbols";
>>>
>>> import { features } from "their-consumer";
>>>
>>>
>>>
>>> if (features[SpecialSymbol]) {
>>>
>>>   // …
>>>
>>> }
>>>
>>> ```
>>>
>>>
>>>
>>> This uses an export named “features”, though in practice it’s pretty
>>> much the same as using “export default”. While the “features” identifier
>>> could theoretically be some other “features” with a different meaning, you
>>> can still detect the presence of your special symbol.
>>>
>>>
>>>
>>> Ron
>>>
>>>
>>>
>>> *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf
>>> Of *Francisco Tolmasky
>>> *Sent:* Thursday, October 15, 2015 10:47 AM
>>> *To:* Logan Smyth 
>>> *Cc:* es-discuss@mozilla.org
>>> *Subject:* Re: Exporting Symbols
>>>
>>>
>>>
>>> There are special features we want to expose if a module defines a
>>> certain key. However, we’d like to not rely on certain names just because
>>> there’s some chance they came up with it themselves. If it was a symbol
>>> that we gave them access to, it would be impossible for this to be the
>>> case, they would have had to grab the symbol from us:
>>>
>>>
>>>
>>> var SpecialSymbol = require(“our-symbols”).SpecialSymbol;
>>>
>>>
>>>
>>> export { whatever as SpecialSymbol }
>>>
>>>
>>>
>>> The difficulty I’m having right now is being torn by two competing “best
>>> practices”: on the one hand, you can’t do what I did above for the runtime
>>> reasons, on the other hand you CAN actually pull it off using the export
>>> default strategy, and in that situation it technically is safer for us to
>>> use our special symbol instead of relying on a string match.
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Oct 15, 2015 at 8:10 AM, Logan Smyth 
>>> wrote:
>>>
>>> The main issue is that modules are statically analysable and
>>> imports/exports are processed before the module executes, and the behavior
>>> of a symbol is by definition a runtime thing. Until the code executes,
>>> there would be no symbol object, and there would be no way to know what
>>> thing was being imported imported / exported.
>>>
>>>
>>>
>>> The primary benefit of symbols is that they are unique, and cannot
>>> collide unless you have a reference to them. Module exports have full
>>> control over their names and don't have the same collision issues that
>>> objects and classes generally do. What is the benefit you are hoping to get
>>> from exposing these values on symbols instead of string keys?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Oct 15, 2015 at 12:14 AM, Francisco Tolmasky 
>>> wrote:
>>>
>>> Not sure if it isn’t the case, but it seems the only way to export
>>> symbols right now is:
>>>
>>>
>>>
>>> ```js
>>>
>>> export default { [Symbol(“something”)]: blah }
>>>
>>> ```
>>>
>>>
>>>
>>> It would be nice if “symbol literals” could somehow be supported. In
>>> particular, I can imagine this sort of thing becoming common:
>>>
>>>
>>>
>>> export { “5.4” as Symbol(“version”) }
>>>
>>>
>>>
>>> Or, even better (but harder since its now more expression):
>>>
>>>
>>>
>>> import VersionSymbol from “symbols"
>>>
>>> export { “5.4” as VersionSymbol }
>>>
>>>
>>>
>>> I’m currently writing an API where there are expected methods stored in
>>> symbols, but this forces exporting one default object instead of being able
>>> to lay them out individual.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Francisco
>>>
>>>
>>>
>>> --
>>>
>>> Francisco Tolmasky
>>> www.tolmasky.com
>>> 

Re: Exporting Symbols

[Rick Waldron]

Symbol has built-in API for making Symbols available across all code
realms:

http://www.ecma-international.org/ecma-262/6.0/#sec-symbol.for
http://www.ecma-international.org/ecma-262/6.0/#sec-symbol.keyfor


You can create a generated key and export it, giving your consumers only
the key, which they can then use to get the symbol.

  // In module.js
  let key = Math.trunc((Math.random() * 0x));
  let sym = Symbol.for(key);
  // use sym throughout the module code
  export { key as features }

  // In program.js
  import { features } from "module";

  console.log(features, Symbol.for(features));


Rick





On Thu, Oct 15, 2015 at 3:38 PM Alexander Jones  wrote:

> Unless of course you needed to export a "features" AND support this magic
> symbol.
>
> On Thursday, 15 October 2015, Ron Buckton 
> wrote:
>
>> Wouldn’t this work?
>>
>>
>>
>> our-symbols.js:
>>
>> ```js
>>
>> export const SpecialSymbol = Symbol("SpecialSymbol");
>>
>> ```
>>
>>
>>
>> their-consumer.js
>>
>> ```js
>>
>> import { SpecialSymbol } from "our-symbols";
>>
>>
>>
>> export const features = {
>>
>> [SpecialSymbol]: true
>>
>> };
>>
>> ```
>>
>>
>>
>> our-features.js
>>
>> ```js
>>
>> import { SpecialSymbol } from "our-symbols";
>>
>> import { features } from "their-consumer";
>>
>>
>>
>> if (features[SpecialSymbol]) {
>>
>>   // …
>>
>> }
>>
>> ```
>>
>>
>>
>> This uses an export named “features”, though in practice it’s pretty much
>> the same as using “export default”. While the “features” identifier could
>> theoretically be some other “features” with a different meaning, you can
>> still detect the presence of your special symbol.
>>
>>
>>
>> Ron
>>
>>
>>
>> *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf Of
>> *Francisco Tolmasky
>> *Sent:* Thursday, October 15, 2015 10:47 AM
>> *To:* Logan Smyth 
>> *Cc:* es-discuss@mozilla.org
>> *Subject:* Re: Exporting Symbols
>>
>>
>>
>> There are special features we want to expose if a module defines a
>> certain key. However, we’d like to not rely on certain names just because
>> there’s some chance they came up with it themselves. If it was a symbol
>> that we gave them access to, it would be impossible for this to be the
>> case, they would have had to grab the symbol from us:
>>
>>
>>
>> var SpecialSymbol = require(“our-symbols”).SpecialSymbol;
>>
>>
>>
>> export { whatever as SpecialSymbol }
>>
>>
>>
>> The difficulty I’m having right now is being torn by two competing “best
>> practices”: on the one hand, you can’t do what I did above for the runtime
>> reasons, on the other hand you CAN actually pull it off using the export
>> default strategy, and in that situation it technically is safer for us to
>> use our special symbol instead of relying on a string match.
>>
>>
>>
>>
>>
>> On Thu, Oct 15, 2015 at 8:10 AM, Logan Smyth 
>> wrote:
>>
>> The main issue is that modules are statically analysable and
>> imports/exports are processed before the module executes, and the behavior
>> of a symbol is by definition a runtime thing. Until the code executes,
>> there would be no symbol object, and there would be no way to know what
>> thing was being imported imported / exported.
>>
>>
>>
>> The primary benefit of symbols is that they are unique, and cannot
>> collide unless you have a reference to them. Module exports have full
>> control over their names and don't have the same collision issues that
>> objects and classes generally do. What is the benefit you are hoping to get
>> from exposing these values on symbols instead of string keys?
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Oct 15, 2015 at 12:14 AM, Francisco Tolmasky 
>> wrote:
>>
>> Not sure if it isn’t the case, but it seems the only way to export
>> symbols right now is:
>>
>>
>>
>> ```js
>>
>> export default { [Symbol(“something”)]: blah }
>>
>> ```
>>
>>
>>
>> It would be nice if “symbol literals” could somehow be supported. In
>> particular, I can imagine this sort of thing becoming common:
>>
>>
>>
>> export { “5.4” as Symbol(“version”) }
>>
>>
>>
>> Or, even better (but harder since its now more expression):
>>
>>
>>
>> import VersionSymbol from “symbols"
>>
>> export { “5.4” as VersionSymbol }
>>
>>
>>
>> I’m currently writing an API where there are expected methods stored in
>> symbols, but this forces exporting one default object instead of being able
>> to lay them out individual.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Francisco
>>
>>
>>
>> --
>>
>> Francisco Tolmasky
>> www.tolmasky.com
>> 
>> tolma...@gmail.com
>>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> 

Fwd: Curried functions

[Bob Myers]

It's trivially simply to write a function `currify` which essentially does
what your proprosed `curry` keyword does.

```js
function currify(f) {
  return function _currify(flen, _f) {
return (...args) => {
  var remaining = flen - args.length;
  return remaining <= 0 ?
_f(...args) :
_currify(remaining, (...args2) => _f(...args, ...args2));
};
  }(f.length, f);
}


function add(a, b, c) { return a + b + c; }
var _add = currify(add);

console.log(_add(1)(2)(3));
console.log(_add(1, 2)(3));
console.log(_add(1)(2, 3));
console.log(_add(1, 2, 3));
```

--
Bob



On Fri, Oct 16, 2015 at 1:15 AM, Michael McGlothlin <
mike.mcgloth...@gmail.com> wrote:

> I dislike that syntax because it makes the order of operations mysterious.
> I like the idea of currying but it should always be clear what is going on.
> A couple parentheses would make things a lot more obvious.
>
> On Thu, Oct 15, 2015 at 8:02 AM, Mark S. Miller 
> wrote:
>
>> const add = a => b => a + b;
>>
>>
>> On Thu, Oct 15, 2015 at 8:08 AM, Niloy Mondal 
>> wrote:
>>
>>> It would be really cool to have syntax to curry functions built into the
>>> languages. Something like...
>>>
>>> ```js
>>> curry function add(a, b) {
>>> return a + b;
>>> }
>>>
>>> add(2)(3); // 5
>>>
>>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Swift style syntax

[Isiah Meadows]

Problem: that is currently a runtime ReferenceError, and it looks
ugly. And operator overloading has already been floated around in the
value types proposal. Having it available for everything isn't that
great of an idea, but for at least value types, it's not a bad one.
And the syntax/semantics here (in your email) is not very good. Also,
what about classes?

```js
class Pair {
  constructor(x, y) {
this.x = x;
this.y = y;
  }

  operator(+)(other) {
return new Pair(this.x + other.x, this.y + other.y)
  }

  // etc.
}
```

I don't like that arbitrary behavior. It's non-obvious. -1 from me.

On Thu, Oct 15, 2015 at 9:40 PM, Yongxu Ren  wrote:
> I vote for operator overloading!
>
> I think this is probably going to be a good way to do it:
> ```
> //in local scope
> let operator(**) = (lhs,rhs) => Math.pow(lhs,rhs);
>
> //class method
> Complex.prototype.operator(+) = function(lhs,rhs){
>   return new Complex(lhs.r+rhs.r,lhs.i+rhs.i);
> }
>
> //global, may not be an good idea
> operator(+) = (lhs,rhs) => lhs*rhs;
> ```
> //this will work for case above
> names.sort(>)
> ```
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Isiah Meadows
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exporting Symbols

[Alexander Jones]

Unless of course you needed to export a "features" AND support this magic
symbol.

On Thursday, 15 October 2015, Ron Buckton  wrote:

> Wouldn’t this work?
>
>
>
> our-symbols.js:
>
> ```js
>
> export const SpecialSymbol = Symbol("SpecialSymbol");
>
> ```
>
>
>
> their-consumer.js
>
> ```js
>
> import { SpecialSymbol } from "our-symbols";
>
>
>
> export const features = {
>
> [SpecialSymbol]: true
>
> };
>
> ```
>
>
>
> our-features.js
>
> ```js
>
> import { SpecialSymbol } from "our-symbols";
>
> import { features } from "their-consumer";
>
>
>
> if (features[SpecialSymbol]) {
>
>   // …
>
> }
>
> ```
>
>
>
> This uses an export named “features”, though in practice it’s pretty much
> the same as using “export default”. While the “features” identifier could
> theoretically be some other “features” with a different meaning, you can
> still detect the presence of your special symbol.
>
>
>
> Ron
>
>
>
> *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org
> ] *On
> Behalf Of *Francisco Tolmasky
> *Sent:* Thursday, October 15, 2015 10:47 AM
> *To:* Logan Smyth  >
> *Cc:* es-discuss@mozilla.org
> 
> *Subject:* Re: Exporting Symbols
>
>
>
> There are special features we want to expose if a module defines a certain
> key. However, we’d like to not rely on certain names just because there’s
> some chance they came up with it themselves. If it was a symbol that we
> gave them access to, it would be impossible for this to be the case, they
> would have had to grab the symbol from us:
>
>
>
> var SpecialSymbol = require(“our-symbols”).SpecialSymbol;
>
>
>
> export { whatever as SpecialSymbol }
>
>
>
> The difficulty I’m having right now is being torn by two competing “best
> practices”: on the one hand, you can’t do what I did above for the runtime
> reasons, on the other hand you CAN actually pull it off using the export
> default strategy, and in that situation it technically is safer for us to
> use our special symbol instead of relying on a string match.
>
>
>
>
>
> On Thu, Oct 15, 2015 at 8:10 AM, Logan Smyth  > wrote:
>
> The main issue is that modules are statically analysable and
> imports/exports are processed before the module executes, and the behavior
> of a symbol is by definition a runtime thing. Until the code executes,
> there would be no symbol object, and there would be no way to know what
> thing was being imported imported / exported.
>
>
>
> The primary benefit of symbols is that they are unique, and cannot collide
> unless you have a reference to them. Module exports have full control over
> their names and don't have the same collision issues that objects and
> classes generally do. What is the benefit you are hoping to get from
> exposing these values on symbols instead of string keys?
>
>
>
>
>
>
>
> On Thu, Oct 15, 2015 at 12:14 AM, Francisco Tolmasky  > wrote:
>
> Not sure if it isn’t the case, but it seems the only way to export symbols
> right now is:
>
>
>
> ```js
>
> export default { [Symbol(“something”)]: blah }
>
> ```
>
>
>
> It would be nice if “symbol literals” could somehow be supported. In
> particular, I can imagine this sort of thing becoming common:
>
>
>
> export { “5.4” as Symbol(“version”) }
>
>
>
> Or, even better (but harder since its now more expression):
>
>
>
> import VersionSymbol from “symbols"
>
> export { “5.4” as VersionSymbol }
>
>
>
> I’m currently writing an API where there are expected methods stored in
> symbols, but this forces exporting one default object instead of being able
> to lay them out individual.
>
>
>
> Thanks,
>
>
>
> Francisco
>
>
>
> --
>
> Francisco Tolmasky
> www.tolmasky.com
> 
> tolma...@gmail.com 
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> 
> https://mail.mozilla.org/listinfo/es-discuss
> 
>
>
>
>
>
>
>
> --
>
> Francisco Tolmasky
> www.tolmasky.com
> 

Re: Curried functions

[Michael McGlothlin]

I dislike that syntax because it makes the order of operations mysterious.
I like the idea of currying but it should always be clear what is going on.
A couple parentheses would make things a lot more obvious.

On Thu, Oct 15, 2015 at 8:02 AM, Mark S. Miller  wrote:

> const add = a => b => a + b;
>
>
> On Thu, Oct 15, 2015 at 8:08 AM, Niloy Mondal 
> wrote:
>
>> It would be really cool to have syntax to curry functions built into the
>> languages. Something like...
>>
>> ```js
>> curry function add(a, b) {
>> return a + b;
>> }
>>
>> add(2)(3); // 5
>> ```
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Curried functions

[Alexander Jones]

Too late, `add(a)` already returns `a + undefined`.

No reason why `const add = curry((a, b) => a + b)` couldn't work though?
Arrow functions have a length property AFAIK.

On Thursday, 15 October 2015, Yongxu Ren  wrote:

> How about making arrow function curry by default?
>
> const add = a => b => a + b;
>
> this will only works in case
>
> add(a)(b);
>
> But it won’t work if you do this
>
> add(a,b);
>
> If we could let arrow to work for both
>
> add(a)(b) and add(a,b)
>
> it will release the full power of functional programming and allow us to
> write code like in OCaml, F# or Haskell
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Exporting Symbols

[Ron Buckton]

Wouldn’t this work?

our-symbols.js:
```js
export const SpecialSymbol = Symbol("SpecialSymbol");
```

their-consumer.js
```js
import { SpecialSymbol } from "our-symbols";

export const features = {
[SpecialSymbol]: true
};
```

our-features.js
```js
import { SpecialSymbol } from "our-symbols";
import { features } from "their-consumer";

if (features[SpecialSymbol]) {
  // …
}
```

This uses an export named “features”, though in practice it’s pretty much the 
same as using “export default”. While the “features” identifier could 
theoretically be some other “features” with a different meaning, you can still 
detect the presence of your special symbol.

Ron

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Francisco 
Tolmasky
Sent: Thursday, October 15, 2015 10:47 AM
To: Logan Smyth 
Cc: es-discuss@mozilla.org
Subject: Re: Exporting Symbols

There are special features we want to expose if a module defines a certain key. 
However, we’d like to not rely on certain names just because there’s some 
chance they came up with it themselves. If it was a symbol that we gave them 
access to, it would be impossible for this to be the case, they would have had 
to grab the symbol from us:

var SpecialSymbol = require(“our-symbols”).SpecialSymbol;

export { whatever as SpecialSymbol }

The difficulty I’m having right now is being torn by two competing “best 
practices”: on the one hand, you can’t do what I did above for the runtime 
reasons, on the other hand you CAN actually pull it off using the export 
default strategy, and in that situation it technically is safer for us to use 
our special symbol instead of relying on a string match.


On Thu, Oct 15, 2015 at 8:10 AM, Logan Smyth 
> wrote:
The main issue is that modules are statically analysable and imports/exports 
are processed before the module executes, and the behavior of a symbol is by 
definition a runtime thing. Until the code executes, there would be no symbol 
object, and there would be no way to know what thing was being imported 
imported / exported.

The primary benefit of symbols is that they are unique, and cannot collide 
unless you have a reference to them. Module exports have full control over 
their names and don't have the same collision issues that objects and classes 
generally do. What is the benefit you are hoping to get from exposing these 
values on symbols instead of string keys?



On Thu, Oct 15, 2015 at 12:14 AM, Francisco Tolmasky 
> wrote:
Not sure if it isn’t the case, but it seems the only way to export symbols 
right now is:

```js
export default { [Symbol(“something”)]: blah }
```

It would be nice if “symbol literals” could somehow be supported. In 
particular, I can imagine this sort of thing becoming common:

export { “5.4” as Symbol(“version”) }

Or, even better (but harder since its now more expression):

import VersionSymbol from “symbols"
export { “5.4” as VersionSymbol }

I’m currently writing an API where there are expected methods stored in 
symbols, but this forces exporting one default object instead of being able to 
lay them out individual.

Thanks,

Francisco

--
Francisco Tolmasky
www.tolmasky.com
tolma...@gmail.com

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss




--
Francisco Tolmasky
www.tolmasky.com
tolma...@gmail.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Curried functions

[Yongxu Ren]

How about making arrow function curry by default?

const add = a => b => a + b;
this will only works in case
add(a)(b);
But it won’t work if you do this
add(a,b);
If we could let arrow to work for both
add(a)(b) and add(a,b)
it will release the full power of functional programming and allow us to write 
code like in OCaml, F# or Haskell___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exporting Symbols

[Francisco Tolmasky]

There are special features we want to expose if a module defines a certain
key. However, we’d like to not rely on certain names just because there’s
some chance they came up with it themselves. If it was a symbol that we
gave them access to, it would be impossible for this to be the case, they
would have had to grab the symbol from us:

var SpecialSymbol = require(“our-symbols”).SpecialSymbol;

export { whatever as SpecialSymbol }

The difficulty I’m having right now is being torn by two competing “best
practices”: on the one hand, you can’t do what I did above for the runtime
reasons, on the other hand you CAN actually pull it off using the export
default strategy, and in that situation it technically is safer for us to
use our special symbol instead of relying on a string match.


On Thu, Oct 15, 2015 at 8:10 AM, Logan Smyth  wrote:

> The main issue is that modules are statically analysable and
> imports/exports are processed before the module executes, and the behavior
> of a symbol is by definition a runtime thing. Until the code executes,
> there would be no symbol object, and there would be no way to know what
> thing was being imported imported / exported.
>
> The primary benefit of symbols is that they are unique, and cannot collide
> unless you have a reference to them. Module exports have full control over
> their names and don't have the same collision issues that objects and
> classes generally do. What is the benefit you are hoping to get from
> exposing these values on symbols instead of string keys?
>
>
>
> On Thu, Oct 15, 2015 at 12:14 AM, Francisco Tolmasky 
> wrote:
>
>> Not sure if it isn’t the case, but it seems the only way to export
>> symbols right now is:
>>
>> ```js
>> export default { [Symbol(“something”)]: blah }
>> ```
>>
>> It would be nice if “symbol literals” could somehow be supported. In
>> particular, I can imagine this sort of thing becoming common:
>>
>> export { “5.4” as Symbol(“version”) }
>>
>> Or, even better (but harder since its now more expression):
>>
>> import VersionSymbol from “symbols"
>> export { “5.4” as VersionSymbol }
>>
>> I’m currently writing an API where there are expected methods stored in
>> symbols, but this forces exporting one default object instead of being able
>> to lay them out individual.
>>
>> Thanks,
>>
>> Francisco
>>
>> --
>> Francisco Tolmasky
>> www.tolmasky.com
>> tolma...@gmail.com
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>


-- 
Francisco Tolmasky
www.tolmasky.com
tolma...@gmail.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss