Re: 'function *' is not mandatory

François REMY francois.remy.dev at outlook.com
Sat Aug 31 18:55:42 PDT 2013


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

         ...


         // next step in generator

         resumeDoSomething = onSecondCall;

         return someYieldedValue;

         

     }


     function onSecondCall(v) {

         

         // continue execution

         ...

         

         // next step in generator

         resumeDoSomething = onExtraCall;

         return someYieldedValue;

         

     }


     function onExtraCall() {

         throw new Error(“The iterator cannot yield more values”)

     }

     


     // generator boilerplate

     var resumeDoSomething = onFirstCalll;


     return { 

         next: function next(v) {

              return resumeDoSomething(v);

         },

         ...

     };

     

}


for which there’s no specific indication required. As noted before in the discussion, most programming languages providing “yield” support do not require anything specific to support it. Interestingly, VB.NET is not one of those, but they deliberately choose some non-function syntax fwiw.


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. 


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".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130901/21f6fbb6/attachment.html>
-------------- next part --------------
_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list