Andreas Rossberg

@nomeata, fair points about constructing the new call. I would assume that the serialiser would not merge but merely extend the type table it gets from the closure. Since we...

@nomeata: > Not sure how much `dyn` offers over `blob`. And it seems a “semantic restriction” that is out of scope for Candid (which at least claims to not include...

Yeah, that's what I based the name `dyn` on. Note that that paper assumes a monomorphic type system, though. There is a follow-up by the same authors plus Remy that...

Wow, thanks! I'm on vacation right now, so only skimmed through so far. Some changes obviously make sense, some I'll need to think about (and swap in all the background...

@di-wu, I'd think the difference is that 2 makes them two distinct packages, which means clients can install them independently, they can be versioned independently, and so on. The ability...

Thanks for the heads-up, it's appreciated. I believe the only blocker for this proposal to move to the last phase is having a second engine implementing it (besides V8). Perhaps...

I'm confused. Can you elaborate how the control flow of `invoke` is different from `call` and how `return_throw` differs from the `throw` in the proposal? The way you describe it,...

> The idea is that you either return normally or you return abnormally. Yes, but that's also the case for `call` under the current proposal (or with evaluation in general,...

@fgmccabe: > 1. The 'static' proposal does not prevent multi-level unwinding. It simply requires code at each level. You still haven't responded to my earlier questions and explained what this...

@KronicDeth, the main difference of Haskell exceptions is due to laziness. Conceptually, it's not that large: (1) they are *imprecise*, i.e., it is not defined which exception you get when...