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