On Mon, Jul 29, 2013 at 3:17 PM, David Jeske <[email protected]> wrote:
> I think it's also worth noting that there was some ML research on > type-polymorphic exceptions implemented using regular-return-values, which > not only solved some interesting exception polymorphism cases but was also > faster than stack-unroll equivalents. It's going to take me some time to dig > up the research reference. Don't think that the following was covered in this thread, apologies if I missed it. ML's module system brings about a curious case with exceptions, for an exception to be handled by name, it must not be hidden within the module, but making the exception public in the module allows callers to raise the exception, i'm told that you can sort of achieve this by having a function which takes the exception as an argument, and returning a bool if it is the, call this from the exception handler and re-raise on false handle exn => if isFooException then ... else raise exn while that does appear to work, it seems by re-raising other exceptions we potentially obscure their origin. I sort of found it interesting in that it doesn't seem to jive with the rest of the ML module system where there is a definite hidden/opaque/public structure to it. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
