On Sat, Aug 31, 2013 at 6:55 PM, François REMY <
francois.remy....@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
>
Whereas
On Sat, Aug 31, 2013 at 3:48 PM, Mark S. Miller <erig...@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 <bren...@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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
