'function *' is not mandatory

Mark S. Miller erights at google.com
Sat Aug 31 20:07:03 PDT 2013

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

> I know pretty well I’m probably not going to convince the believers here,
> but this whole “we need an indication at the beginning of the function”
> thing is kinda not making sense.
> For starter, the generator function always starts at its first line. If
> what you {Till Schneidereit} mean is that the execution can resumes at
> another line when someome call .next() on the iterator, then we speak about
> something else, which is absolutely no different than
> function SomeIterator() {
>      function onFirstCalll(v) {
>          // continue execution

On Sat, Aug 31, 2013 at 3:48 PM, Mark S. Miller <erights at google.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.

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

Granted that promise-returning functions can be difficult to grasp for
their own reasons. But without one of the above markers they can't create
this particular confusion.

> The best way to tell what your function does is to choose a name that
> makes clear how its internal working behaves, and possibly some
> informational return-type information (via a comment or Typescript-like
> preprocessors), not by adding a distracting and non-self-descriptive star
> symbol next to the function keyword.
> 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.
> *De :* Till Schneidereit
> *Envoyé :* samedi 31 août 2013 18:05
> *À :* Brendan Eich
> *Cc :* es-discuss
> On Sun, Sep 1, 2013 at 2:43 AM, Brendan Eich <brendan at mozilla.com> wrote:
>> Lots of constructors/factories out there. An essential (see Aristotle)
>> argument for why function* for generator syntax (ignoring trumping reasons
>> 1&2) must say why *this* particular factory needs special (a la function*)
>> head syntax.
> For all non-generator functions, one important assumption for reading them
> holds: they always start with the first instruction, and any (potential)
> deviations from linear control flow are visible exactly where they (might)
> happen. Not so for generators: to understand what invoking a generator
> might do, you have to look at all the potential entry points, i.e., all
> instructions following a yield in the control flow. If you want to do more
> localized reasoning and are interested in a specific invocation, you also
> have to reason about which might be the relevant one. Granted, that is
> essentially state and any function's control flow can be state-dependent,
> so this point might be less important.
> Still, having to look at an unknown number of entry points to understand
> how control flows through a piece of code seems like something you'll want
> to know about. Without searching the code for "yield".
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130831/0e78b392/attachment-0001.html>

More information about the es-discuss mailing list