'function *' is not mandatory

François REMY francois.remy.dev at outlook.com
Sat Aug 31 20:34:08 PDT 2013


> [...] The only contextual knowledge the reader
> needs in order to know this is that there are no
> intermediate function definitions within f 
> wrapping code sequence 2 -- i.e., that code
> sequence 2 is code of the function f itself, as
> opposed to code of a function within function a.
> It suffices to check that there are no unbalanced function definition starts in code sequence 1. [...]
>
> Your "function onFirstCalll(v) {" obviously violates this condition in precisely the way I meant.

You can find a yield statement as quickly as you can find much more quickly than you can find whether any existing inner function is used for async patterns or not. This "introductory keyword" stuff is a belief which cannot be backed by any assessable fact, because it simply do not improve code readability.



> >  In all honesty, Async functions and 
> > Promise-returning functions can very often
> > be more challenging to grasp than iterators and
> > there’s no “syntax flag” for those things.
> 
> For async functions:
> 
>    Today: "Q.async(function*"
> 
>    Hopefully in ES7: "function!"

If the goal is to make sure when we will /really/ need some innovative syntax in the future we will have run out of every easy to write token combination, as well as transforming JS into a cryptic Perl-like code, yes, that seem great to me ;-) 

If the goal is to make the code clear, sorry using random glyphs in a place where they aren't expected doesn't seem like the best plot for a success story. I hope the directors of the JS movie are good and know what they're doing. I've come to learn the TC39 committee members usually have good ideas even if they seem bad initially. I hope this is the case again this time...
  


By the way, you didn’t reply to this: 
> Also, I totally dislike the fact I can’t use “yield” in a lambda function because of this star thing. I can totally imagine a function taking an iterator as argument, and being able to use a lambda function could totally make sense to define the iterator. The star syntax is an arbitrary and not very useful restriction, in my opinion.
 
If even async code is somehow going to use a custom syntax, we will end up in a case where lambda's will only cover a small fraction of the function needs, and you may have to refactor your lambda to functions in some cases. This seems like a bummer to me. 


More information about the es-discuss mailing list