> [...] 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.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
