Curried functions

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

Exporting Symbols

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

Re: Exporting Symbols

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

Import statements & destructuring

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

Re: Swift style syntax

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

Re: Re: Swift style syntax

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

Re: Swift style syntax

> 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

Re: Re: Curried functions

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

Re: Re: Curried functions

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

Re: Re: Curried functions

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

Re: Curried functions

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;

Re: Exporting Symbols

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

Re: Exporting Symbols

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

Fwd: Curried functions

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 ?

Re: Re: Swift style syntax

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

Re: Exporting Symbols

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"); > > ``` > > > >

Re: Curried functions

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

Re: Curried functions

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

RE: Exporting Symbols

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";

Re: Re: Curried functions

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

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