'function *' is not mandatory

Mark Miller erights at gmail.com
Sat Aug 31 20:47:43 PDT 2013


On Sat, Aug 31, 2013 at 8:34 PM, François REMY <
francois.remy.dev at outlook.com> wrote:

> > [...] 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...
>

That is nice to hear, and quite a track record to live up to. On behalf of
all TC39 if I may, thanks.

However, I cannot honestly leave you to expect this to happen again in this
case. I think we've stated the case for "function*" as clearly as we're
going to. It is a tradeoff. Depending on one's weightings of the issues,
one can honestly disagree. I expect that's all that's going on here.

In any case, because of Brendan's reasons #1 and #2, our disagreement on #3
doesn't actually matter. We need some distinguishing syntactic marker
regardless. No one has suggested anything less painful than "function*"




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

I have previously lamented this problem on es-discuss and asked for
suggestions. I agree that this problem is genuinely painful and continue to
welcome suggestions.




> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130831/9d70c6c6/attachment.html>


More information about the es-discuss mailing list