Re: Re: Proposal: expression mode (=)

[Yongxu Ren]

Isiah, In your case, if we do
```
var x = = { a }
```
there isn't much difference from the `do expression`, actually, it might be
worse since it looks confusing. if it can not be omitted, I'd rather stay
with `do`.

The intent for this proposal is to allow writing better functional code in
javascript. IMO, the `do expression` is a good start, but I think using `=`
(and other operators) is a more elegant since it can be omitted.

Actually, I think I have a better idea to put it together:

*1. besides defining a function, if the block can be legally be replaced by
an expression, while otherwise it would cause parsing error, convert it to
expression block*

*2. if the case is ambiguous or it is been used in function declaration,
adding `=` (actually, using `do` here isn't a bad idea either, but can be
quite ugly for defining function) will enforce block to be parsed as
expression*

The goal is to make javascript more functional friendly.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: expression mode (=)

[Yongxu Ren]

Isiah,
The reason for `=` instead of the `do expression` is to write functional
code without extra syntax. I do not think there are any indistinguishable
or 'very confusing' case, though I am aware the *Object Property Shorthand`
that been introduced in ES6 might cause some problems.

Here is what I think that may resolve this problem
for your concern,
```
var b = 1
var a = b
= { c }
```

the solution is to make `Object literals` to have higher parsing priority.

if `c` is a variable, it will be parsed as `object literal`, otherwise it
is considered as scope and been parsed as expression block.

ex.
`var x = { a }` will be parsed as `var x = { a: a }`
`var x = { a() }` will be parsed as `var x = a()`, under current specs it
would be syntax error.

In this case, this proposal should not cause any confusion IMO.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: expression mode (=)

[Yongxu Ren]

For supporting label, yes that is kinda a problem.
However, IMO jumping around labels is an anti-pattern in functional
programming, I don't think it needs to be supported. Syntax error might be
the most reasonable way in this case.

for 'match', while it is just some thought. I wasn't intended to proposal
it but just showing potential of  extending `= expression`.

Personally I do not think label would be a problem for implementing this
pattern.

here are two possible solutions I can think of:

1. If `[name]:` exist inside the block, just parse it as object and throw
error if the structure doesn't match.

2. If `[label]:` does exist inside the block,  only allow in scope jump.
(label not accessible outside the scope)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: expression mode (=)

[Yongxu Ren]

Yes, it does the exact same thing.
I think using = and operators is a bit cleaner than 'do'.
However, The biggest advantage for this feature is you can write functional
code without extra syntax.
Allowing block to return value will allow you to write concise code like in
ocaml Haskell or scala.

On Sunday, October 30, 2016, Olivier Lalonde <olalo...@gmail.com> wrote:

> Sounds like the "do expressions" proposal. http://wiki.ecmascript.org/
> doku.php?id=strawman:do_expressions
>
> On Sat, Oct 29, 2016 at 5:32 PM, Yongxu Ren <renyon...@gmail.com
> <javascript:_e(%7B%7D,'cvml','renyon...@gmail.com');>> wrote:
>
>> potentially, this syntax can be extended to functions
>> ```
>> function f() ={stat}
>> // is equivalent to
>> function f() {return stat}
>>
>>
>> let f = () => ={stat}
>> // are equivalent to
>> let f = () => stat
>> ```
>>
>> it can also be applied to `try...catch` and more, such as
>>
>> ```
>> // pattern matching
>> match(expr) {
>>   pattern1:={
>> //block
>>   }
>>   pattern2:={
>> //block
>>   }
>>   pattern3:={
>> //block
>>   }
>> }
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> <javascript:_e(%7B%7D,'cvml','es-discuss@mozilla.org');>
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> - Oli
>
> Oli Lalonde
> http://www.syskall.com <-- connect with me!
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Proposal: expression mode (=)

[Yongxu Ren]

potentially, this syntax can be extended to functions
```
function f() ={stat}
// is equivalent to
function f() {return stat}


let f = () => ={stat}
// are equivalent to
let f = () => stat
```

it can also be applied to `try...catch` and more, such as

```
// pattern matching
match(expr) {
  pattern1:={
//block
  }
  pattern2:={
//block
  }
  pattern3:={
//block
  }
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Proposal: expression mode (=)

[Yongxu Ren]

This proposal makes it easier to write functional code, you can convert
statements block into expressions producing a useful result and plugging
that back into an expression context.

This proposal is an alternative to the 'do expressions'.


Prepending `=` will automatically convert `if...else`, `switch...`, `block`
into statement that returns last inner statements value by default.

examples:

```

// the following 3 lines are equivalent

console.log(=if (expr) {a} else {b})

console.log(=if (expr) a else b)

console.log(expr ? a : b)

// print the value of statement3

console.log(={

  statement1

  statement2

  statement3

})

```


If the left hand side is an expression or operator, '=' can be omitted

```

LeftHandSideExpression = if (condition)

   statement1

[else

   statement2]

let someVal = LeftHandSideExpression * if (condition)

   statement1

[else

   statement2]

```

examples:

```

// the following 3 examples are equivalent

let x = if (expr) {a} else {b}

let x = if (expr) a else b

let x = expr ? a : b


let x = {

// statements here

console.log('print unicorn')

y // will assign y to x

}

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

Re: Decorators for functions

[Yongxu Ren]

I don't think

> ```@@ or @() or @::meomize```

would really help much, you can tell what the decorator does by simply
looking at its name. And looks like you can not use @ and @@ for the
same decorator function
without adding extra condition checking inside the function.

There are two patterns that we have discussed here, they are actually quite
distinct. I still think we should support decorator on variables, but maybe
we should have 2 distinct syntax for the normal decorators and "ambient
decorators"(from Jonathan's post):

1.  decorator that alter the code behavior,  the currently proposed
decorator. Such as ```@memoize```

2. decorator that absolutely does not alter the code behavior, only used
for optimization, checking or debugging. Instead of @, a distinct syntax
will be much clearer ex.```@annotatition@``` (Maybe it should be called
annotation instead?):
```
@deprecated@

@number,number=>string@/*type checking*/

@debug("this message will only print in development mode")@
```

it sounds like terrible idea to have a decorator in code that you can not
figure out if it will alter the code behavior by looking at it. I do like
to see all the new ideas been added into javascript, but it is also
necessary to eliminate the ambiguity whenever possible.


On Thu, Oct 22, 2015 at 11:20 AM, Jonathan Bond-Caron <
jbo...@gdesolutions.com> wrote:

> On Thu Oct 22 07:44 AM, Andreas Rossberg wrote:
> > > determined at creation time, allowing for massive engine optimization,
> >
>
> Ya I'm not sure from which hat "massive engine optimization" comes from?
>
> What's meant is likely using decorators as annotations (compile time
> optimizations hints):
> http://www.google.com/patents/US7013458
>
> Or 'ambient decorators':
>
> https://github.com/jonathandturner/brainstorming/blob/master/README.md#c6-ambient-decorators
>
> There's 2 patterns (maybe more?):
> (a) Tagging a 'tree transformation'  on a node.
> (b) Metadata at compile time on a node.
>
> The thing about (b) is it can easily live outside of the code (like in
> typescript where you have an optional header/declaration file)
>
> With (a), it seems more conservative to see how it gets used with classes
> before bolting on to functions (opinion: end result in java is not
> something to be proud of).
>
> ___
> 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: Decorators for functions

[Yongxu Ren]

Andrea,

My point wasn’t to implement something that allows the decorator function to 
figure out the difference between class and function. The point is to be able 
to show the difference in your code, so that it can tell the developer what the 
code is doing.

Also, the [‘ambient decorator’ 
](https://github.com/jonathandturner/brainstorming/blob/master/README.md#c6-ambient-decorators
 
)
 Jonathan mentioned is what I think why we should have a new syntax 
for(decorator that absolutely does not alter the code behavior, only used for 
optimization, checking or debugging should have different syntax from decorator 
that alter the code behavior).


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

Re: Re: Decorators for functions

[Yongxu Ren]

I think I am quite off topic, how about this solution:

If we restrict only use decorator on class

And use ```@annotation@``` decorator that absolutely does not alter the code 
behavior for functions, for the ambient case?___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Decorators for functions

[Yongxu Ren]

I agree with Andrea, basically nothing after es3 is a "must have", if we
apply the same argument.

I see a lot possibilities of decorator, I think it would be great if it can
be used on any lvalue, or even statements.

some of the application I can think of:
```
//static type checking
@type(number,number,number)
function f(a,b){

}

@debug(unitTestForFunction)
let f = (x) => .

@parallel
for(...){...}
```
I think the best part of decorator is it can be processed by compiler or
polyfilled, so we can use them to instruct translator such as babel, to do
extra checking during development and drop them in production. It can also
be used by JET, if supported. Extra type checking, debugging can be ignored
by native engine, polyfilled to function that does nothing(as fallback if
no native support), or optimized as static typed function for performance.

I'd love to see a limitless decorator that also allows browser/compiler to
receive hints from developers.

On Wed, Oct 21, 2015 at 7:12 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> I agree it's not a "must have", considering what we lose if applied
> (portability) + you are back to broken portability with @meomize function
> ... VS meomize(function)
>
> So, I think portability is more important than some edge case without
> parenthesis around and if really wanted as a pattern,there is a workaround.
>
> Create an object to unpack it ... why not ... named functions? why not ...
> I'm used to write `{method:  function method() {}}` for debugging sake and
> I like named functions but going even more dirty with the workaround maybe
> an array to unpack would  make it less maintainable but less verbose too.
>
> It will still be portable,  which is all it matters to me.
>
> Regards
>
>
>
>
>
> On Wed, Oct 21, 2015 at 1:01 PM, Alexander Jones  wrote:
>
>> Although this works, it seems like a bit of a violation of
>> say-what-you-mean and dont-repeat-yourself to me. You have to write the
>> name of each function twice, and you are defining a shorthand object
>> literal just for the sake of unpacking it.
>>
>> If we must have syntax for this, I'd propose hijacking @ to mean general
>> paren-free invocation, using the same precedence rules as Coffee:
>>
>> ```js
>> const fibonacci = memoize(function(n) {...});
>> const fibonacci = @memoize function(n) {...};
>> const fib100 = @fibonacci 100;
>> @window.alert "If this syntax works for functions, why not let it work
>> for anything?";
>> ```
>>
>> But I must ask - why *exactly* do people have a problem with the extra
>> brackets again? Is it really just because we don't have good paredit or
>> other tree-based editing for JS yet? (Or do we?)
>>
>> On Wednesday, 21 October 2015, Andrea Giammarchi <
>> andrea.giammar...@gmail.com> wrote:
>>
>>> Again, everything can be defined in a similar way, actually granting
>>> those function  cannot posibly be declared or redefined differently, being
>>> constants.
>>>
>>> ```js
>>>
>>> const {
>>>   assert,
>>>   log,
>>>   add
>>> } = {
>>>   @conditional(DEBUG)
>>>   assert(condition, message = "assertion failed.") {
>>> if (!condition) throw new Error(message);
>>>   }
>>>
>>>   @conditional(TRACE)
>>>   log(message) {
>>> return target => function () {
>>>console.log(message);
>>>return target.apply(this, arguments);
>>> };
>>>   }
>>>
>>>   @metadata("design:paramtypes", () => [Number, Number])
>>>   @metadata("design:returntype", () => Number)
>>>   function add(a, b) {
>>> return a + b;
>>>   }
>>>
>>> };
>>> ```
>>>
>>> Beside that, that gist is completely unreadable to my eyes, I guess it
>>> would take some time to be maintained as well if that was production code.
>>>
>>> The work around fixes all that, it keeps portability of the current
>>> proposal, and it ensure log will always be that log and nothing else in
>>> that very same scope +  strawberry on  top, less writing and always named
>>> functions.
>>>
>>> How cool is that?
>>>
>>> Best Regards
>>>
>>>
>>>
>>>
>>> On Tue, Oct 20, 2015 at 8:26 PM, Ron Buckton 
>>> wrote:
>>>
 I can think of numerous examples of how decorators could apply to
 functions, and I’ve added them to a gist
  [1] for easier
 consumption. It’s true that simple decorators for functions can work as
 simply as function calls, but this becomes a bit unwieldy if you need to
 compose multiple decorators on a single function.



 Consider a scenario combining decorators providing runtime type
 information as an annotation with one that adds runtime type checking. With
 decorators this might be:



 ```js

 @paramtypes(() => [Number, Number])

 @returntype(() => Number)

 @checked

 function add(x, y) { return x + y }

 ```



 If I just use function expressions, this is 

Re: Re: Decorators for functions

[Yongxu Ren]

Alex,

```
const fibonacci = memoize(function(n) {...});
```

this is actually a very good example that why we should let decorator do
the job.

Regardless the name ```memoize``` or memorize, whatever,

How can you tell if fibonacci is a function, a list, or just a number?

That is why we should allow decorator on function
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Curried functions

[Yongxu Ren]

As long as the total numbers of argument and types are consistent, which
are mostly true for curry functions, it should be able to easily optimized.

Also, the polyfill for curry is just way too slow.


On Sat, Oct 17, 2015 at 11:51 PM, Isiah Meadows <isiahmead...@gmail.com>
wrote:

> Here's what I see as what's being proposed here. Correct me if I'm wrong.
>
> Function currying means it can be partially applied when only given
> some of its arguments. For example:
>
> ```js
> var add = _.curry(function (a, b, c) { return a + b + c })
>
> add(1)(2)(3) === 6
> add(1, 2)(3) === 6
> add(1)(2, 3) === 6
> add(1, 2, 3) === 6
>
> var add3 = add(3)
>
> add3(2, 1) === 6
> add3(2)(1) === 6
>
> var add5 = add(3, 2)
>
> add5(1) === 6
> ```
>
> That's exactly the behavior in Underscore's and Lodash's `_.curry()`.
> And that's exactly what I (and most others) would expect.
>
> -
>
> As for Yongxu Ren's idea, that wouldn't be very performant, as engines
> have never been made to handle very highly nested closures very well.
> That's a great idea in statically typed, mostly pure functional
> languages (Haskell and OCaml both do that), but in languages that
> accept multiple arguments for a single function like Java or Python,
> it's hard to optimize at all. JavaScript is no exception. It's also
> cheaper to do a function length comparison than an unavoidable
> `IsCallable` check for each argument passed (which that would
> require).
>
> On Fri, Oct 16, 2015 at 11:41 PM, liorean <lior...@gmail.com> wrote:
> >
> > On 17 Oct 2015 04:48, "Yongxu Ren" <renyon...@gmail.com> wrote:
> >>
> >> How about we use a different approach?
> >>
> >> Instead of allowing ```a(b)(c)``` for ```let a = (b,c) => b+c;```,
> >>
> >> Maybe we can use ```a(b,c)``` for ```let a = b => c => b + c```?
> >
> > Would that do any of the useful stuff you could reasonably want either
> > currying or partial application for, though? I mean the main use is that
> it
> > allows us to do
> > let d=a(b);
> > ...
> > d(c);
> > And I don't really see how your desugaring a single multiple argument
> > application into several single parameter curried functions allows that
> > usefulness.
> >
> > It's the multiple applications to fill single parameter list thing that
> is
> > the most useful part of it, mostly as it allows caching the closure at
> any
> > step for reuse, not single application to fill multiple sequential single
> > parameter lists. Also, consider rest parameters, defaults etc. and
> whether
> > doing what you want for the simple example case would have weird or
> possibly
> > ambiguous meaning. Also, what happens to this value if the functions are
> old
> > style and not new style?
> >
> >
> > ___
> > 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: Re: Curried functions

[Yongxu Ren]

Michał, thanks for pointing that out. Yes, optional options as the last
optional parameter does exist, in multiple libraries. But I is there really
existed any library that using arrow function like this? I doubt it.

I think arrow function should only be used for lambda expression, callback
and short in block function. It does cause incompatibility if anyone used
arrow function for API interface, but doing that is anti-pattern.

Curry function are often used in iterations, a slow polyfill will defeat
the purpose.
Considering this case:
```
map (add 1) [1..10]
```
I think native syntax support for curry will be a good thing, it can be
used for JIT.
However, javascript already too big, so why not just let existing syntax to
do the work?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Return value of forEach

[Yongxu Ren]

I like the idea, I don't see why it might break compatibility and this is
also faster than map if list is immutable.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Curried functions

[Yongxu Ren]

How about we use a different approach?

Instead of allowing ```a(b)(c)``` for ```let a = (b,c) => b+c;```,

Maybe we can use ```a(b,c)``` for ```let a = b => c => b + c```?
___
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: 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

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