Re: [compiler-dev] Re: Generators asynchronous methods and coroutines.

47 views
Skip to first unread message
Message has been deleted
Message has been deleted

Florian Loitsch

unread,
Aug 7, 2014, 7:07:54 AM8/7/14
to Andrew Mezoni, Dart Compiler Developers, Kevin Millikin
Hi Andrew,
we have already started on this transformation. It will be based on the new IR that is currently developed for the dart-to-dart compiler. It is CPS based and therefore quite suitable for this task.
Kevin already wrote a prototype in ocaml.
I don't think that keeping stack frames is currently a priority (although it would be nice). For now, we focus on getting something out.

On Thu, Aug 7, 2014 at 10:24 AM, Andrew Mezoni <andrew...@gmail.com> wrote:
If there is no interest, it means that you already have everything ready.

среда, 6 августа 2014 г., 21:29:09 UTC+6 пользователь Andrew Mezoni написал:
Does it make sense to start (for me) developing generators for asynchronous methods and coroutines?
Or have you got everything ready but you just do not rush commit them?
P.S.
I have not thought about the implementation of generators for the Streams, but I do not think that this is not a solvable problem.
P.S.P.S.
I think that at beginning would be very good to prototype them as the code transformers which written in the Dart language (in conjunction with the analyzer).
Just one disadvantage of this approach. It requires creating the source maps, or generating some annotations, for new statements and declarations.

You've already thought through how to implement nested try/catch/finally (TCF) states in state machine (SM)?
They should work with both sync exceptions (via throw "e") and with the stored (inside Futures) async exceptions without losing stack frames.
How you propose to direct the control flow from the inner TCF to the outer TCF's?
What about the way and place for handling (sync and async) exceptions inside intermediate (between inner and outer) TCF's in SM?
You already have answers on similar questions?

P.S.
Small proposal.
Add "hasTail" property to statement and expression nodes.
This prevent analyze (plunge into) code twice for determing that statement and expression has sync control flow divider.
Eg.

if(await a) {
}

ifStatament.hasTail is true because it contains await expression which (in fact) has tail.
ifStatament.thenStatament.hasTail is false because it not required multiple states for it implementation (has no tails).

To unsubscribe from this group and stop receiving emails from it, send an email to compiler-dev...@dartlang.org.



--
Give a man a fire and he's warm for the whole day,
but set fire to him and he's warm for the rest of his life. - Terry Pratchett
Reply all
Reply to author
Forward
0 new messages