On Thu, Aug 29, 2013 at 9:50 AM, Jonathan S. Shapiro <[email protected]> wrote: > On Thu, Aug 29, 2013 at 9:31 AM, Matt Rice <[email protected]> wrote: >> >> On Thu, Aug 29, 2013 at 8:57 AM, Matt Rice <[email protected]> wrote: >> > 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. >> >> FWIW i'm not really sure that the ability to suppress raising an >> exception has any practical value, because the raising process >> includes the source location of the raise thereby allowing one to >> differentiate between the same exception raised multiple times, where >> error codes being reused, do not (outside of a debugger). > > > I actually see the ML solution as perfectly consistent with the rest of the > module system. The type of an object has to be in scope in order for you to > do anything with it. > > In a different language design, the way to prevent external fabrications of > those exception objects would be to make the constructors visible only > within the assembly. ML doesn't have that concept.
I Agree, but ML _does_ have that concept, It just doesn't have it for exceptions AFAICT, you can afaict have an exception whos constructor requires an object with a hidden constructor, but then you can take the opaque object out of an exception created by the module, to throw one from outside the module... anyhow _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
