> 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