Hi Romain!


> Some issues:
>
> - One needs to separate exceptions into two groups, the ones that you
> are actually interested in typing (their purpose is to kill the program,
> so to speak) and the ones that you are not (they are actually used for
> control flow).
>
I would not like such a separation, unless the user can decide the kind of
each exception (did you say burdensome? ;o). This kind of separation is
pretty much the reason why there are errors and exceptions in Java, IIRC.


>
> - I'm not sure it is easy to infer. For instance, in:
>
> let f g =
>   g 1
>
> should we just assume that g raises nothing?

No, we should assume g raises something, and that f raises the same.


> Or should we use some kind
> of row variable, like:
>
> let f (g: 'a raise ([< ] as 'raises): 'b raise 'raises =
>   g 1
>

Yes more like that


>
> But then what about:
>
> let f
>     (g: 'a raise ([< ] as 'raises_h)
>     (h: 'a raise ([< ] as 'raises_g): 'b raise [ 'raises_g | 'raises_h ] =
>   g 1 + h 2
>
> is it sound to have those abstract union types [ 'raises_g | 'raises_h ]?
>

I guess it is not easy because 'raises_g and 'raises_h may have
incompatibilities (same constructors with different arguments). Since you
worked on union of abstract polymorphic variant types, I guess you know
pretty well how difficult that would be ;o).


>
> Do we want all functions to have these convoluted types?
>
Representing those types could be optional most of the time. The only place
where they would be important would when catching exceptions, to have the
compiler check for exhaustivity.


>
> --
> Romain Bardou
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>