On 12/18/06, Bruno De Fraine <Bruno.De.Fraine@vub.ac.be> wrote:
> I think support in the type system for exceptions would look a lot
> like that for polymorphic variants. You can do some of the things you
> suggest with them, but there are some important shortcomings (other
> than the obvious issue that an exception aborts the normal control
> flow and moves up the stack until it is handled).

Agreed, I wonder if a proof-of-concept syntax extension could be
written to take advantage of this similarity?  (Of course its
performance would be abysmal! but it would be a good way to try such a
system in a larger project.)

> > val List.iter: ('a -> unit raises 'b) -> 'a list -> unit raises 'b
>
> val iter : ('a -> ([> `Val of unit ] as 'b)) -> 'a list -> 'b = <fun>
>
> This is a bit different from how you describe the type, but in
> principle I can agree: "iter will have the same return type as the
> argument function; this should include a normal unit value".

Yes, this type seems to fit well.

> > val catch_failures: ('a -> 'b raises [Failure of string | 'c]) -> 'a
> > -> 'b raises 'c
>
> val catch_failures :
>    ('a -> ([> `Failure of string | `Val of 'c ] as 'b)) -> 'a -> 'c -
>  > 'b =
>    <fun>
>
> It is problematic that the final return type will be the same as that
> from the argument. I.e. the exception that we catch is not removed:

OcamlExc (http://caml.inria.fr/pub/old_caml_site/ocamlexc/ocamlexc.htm)
seems to make some headway into this problem by doing flow analysis...
whether it can handle this specific case I'm not sure but I wouldn't
be surprised.

I also know of no way to express this using variants.  Although we
could say something like

val catch_failures : ('a -> ([> `Failure of string | `Val of 'c |
everything_else ] as 'b)) -> 'a -> 'c -> everything_else

and replace the default match case with a case matching [>
everything_else], there's currently no way (that I know of) to create
the "everything_else" type abbreviation, short of enumerating all
known exceptions manually.

- Chris