]> > No. The problem is it breaks abstraction. i disagree. the exceptions thrown are part of the specification the function tries to meet. > For example consider > > map f list > > which currently has signature > > ('a -> 'b) -> 'a list -> 'b list i dont see a problem here. simply use exception specification polymorphism: map has type forall A B E: (A -> B throws E) -> list[A] -> list[B] throws E. while i have not thought about this in detail, i dont think there's a type theorectic problem with this. > The problem is that exceptions thrown are typically > implementation details so it would often be an error > to include the exception type in the function signature. i do not think that the exception thrown is an implementation detail > Well, exceptions are 'really' wrong: they're 'really' a constraint > on the type of the argument, for example > > divide: float -> float not zero -> float > > but expressed negatively (throws divide by zero). that's one way of looking at it. another would be to say we have dependent types ... unfortunatly neither rich specifications nor type dependencies lead to decidable type inference so we need to be less precise. martin ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners