Francis McCabe

Follow on note: with this proposal, the determination of the 'catcher' for any exception *is* statically determined. Not sure how to make that clearer. On Thu, Jun 27, 2019 at...

Thank you for your response. Specific points: 1. The 'static' proposal does not prevent multi-level unwinding. It simply requires code at each level. (Haskell's approach to exceptions is radically different...

This is not quite accurate. Focusing on Java, all exceptions are subclass of Throwable. If you want to model unchecked exceptions in a checked world, you report a Throwable for...

(I am writing another message that rephrases the proposal. This is simply in response to specific questions raised) 1. As far as I am aware, my proposal does not require...

This counts as a restatement of my proposal; hopefully clearer than before. 1. Exception values are just any wasm value. (Not anyref, nor any variant thereof; although in practice they...

Thanks for the response; however, I am not sure I follow your reasoning... 1. I am aware of the functional approach. However, this proposal specifically does not require the kind...

Thank you for clarifying that index space issue. I had missed it. However, if the only purpose of the exception index is to distinguish between java exceptions and C++ exceptions...

How does nominal types solve this issue?

> > To get a sense of what that means, consider the line assert elem_type == > Integer.rtt;. Right before this line, the snapshot-in-time-type is "[ints > : Array, elem_type...

That is a matter of opinion. Personally, I find it confusing. On Tue, Jul 16, 2019 at 12:51 PM Andreas Rossberg wrote: > The following works perfectly fine in the...