On Mon, Aug 25, 2014 at 2:17 AM, Salvador de la Puente González < [email protected]> wrote:
> Sorry, I sent this only to Tab. > > On 20 Aug 2014 17:39, "Tab Atkins Jr." <[email protected]> wrote: > > > > > On Wed, Aug 20, 2014 at 5:00 AM, Salvador de la Puente González > > <[email protected]> wrote: > > > Hello. > > > > > > Just a little presentation before the proposal. I'm Salvador de la > Puente > > > González (you can call me Salva, please). I'm working for Telefonica > I+D in > > > Mozilla Firefox OS and I'm a front-end developer, you can know more > about me > > > in http://unoyunodiez.com and my github user is > https://github.com/lodr > > > > > > Now, these day I was thinking about a generator feature. I have a use > case > > > for a transpiler I'm developing: in the source language you have > procedures > > > much more like Linux processes. The language have a block sentence > clone for > > > cloning a procedure. After cloning, father procedure simply ignores the > > > block while coned procedure execute sentences inside. Like an > automatized > > > |pid = fork() if (pid != 0) { .... }|. > > > > > > Now I'm addressing this problem from a AST perspective, transpiling > > > procedures to a special generators able to fall through their sentences > > > until reaching a specific yield. > > > > > > But I think it could be easier if I could do something like > > > |generator#clone()| returning a new generator object. This new > generator is > > > paused of the same yield as the original one and have a new variable > > > environment with a shallow copy of the original's variable > environment. The > > > variable environment's parent chain would be the same as the original > one. > > > > > > Notice this is not related with data preservation as most of the > objects > > > being used by original generator will be shared with the new one > (although > > > this could be addressed as well) but with execution state. > > > > Generators produce iterables, and you can just use a tee() function to > > "clone" an iterable. It's not hard to define yourself, and Python has > > a reference implementation: > > https://docs.python.org/2/library/itertools.html#itertools.tee > > > > tee() function has two main problems. First and most important, it does > not allow you to communicate different information by using send() on the > new generators. The new generators, though independent, are actually tied > to the state of the original iterator which leads to the second problem: > the waste of space. You need to keep repeated values for each of the cloned > generators. > > My proposal performs only a shallow copy of the current state and most > important, the execution state which allow you to send different > information for the next iteration step. They are real independent > generators. > > > > In the same way, to provide a complete control over execution state > inside > > > generators I would like to propose |generator#goto(yieldLabel)| that > could > > > allow the developer to transfer the execution cursor to a labeled yield > > > sentence. The result of the yield sentence could be the extended with > the > > > label for that yield. > > > > > > I know it does not suffice to be a cool feature but I think it could > trigger > > > very interesting uses cases and applications in backtracking or temper > > > algorithms. > > > > You can currently pass values back into the generator by passing an > > argument to .next(), and the generator can use that to do whatever it > > wishes, such as changing its internal state or jumping to a label. > > AFAIK, jumping to a label is not possible in ES5. You can only skip a > labelled sentence. Indeed you can use the next information for changing the > state. It's how I'm doing it right now but transpiling the functions this > way is quite obscure. > > I don't know if there are goto discussions in this list but it is one of > my concerns, if JS is becoming something like the "high level target > language of the web", to provide a powerful enough flow control sentence > like goto. > > I know the dangers behind this sentence and this is because I propose to > limit its usage inside generators where scope is controlled and limited. > You can not jump between functions and the jumping is controlled > externally. The proposed goto() method does not send or advances the > generator, it only changes the execution point. It can be completed with > gen#yields() which would return all labels for labelled yields. > Superficially, this sounds like a switch statement. I have a hard time envisioning something that is more powerful and doesn't cause lots of problems. switch (start) { case 1: yield something; // fall through case 2: yield something; } Cheers! > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
