]> On Wed, 2003-11-19 at 03:49, Martin Berger wrote: > but isn't this snowballing exactly what you want? No. The problem is it breaks abstraction. In C++, the problem was for a templated higher order function .. which is common if you remember classes have methods .. there is no way to tell what exceptions a user defined function passed as an argument might throw. You cannot simply use a type constraint because it amounts to a restriction on the implementation. For example consider map f list which currently has signature ('a -> 'b) -> 'a list -> 'b list Well, how do you account for a function such as: let f x = 1 divide x which might throw division by zero? The only real solution is to not use exception specifications at all in higher order functions... which makes them pretty useless in a language like C++ or Ocaml. > you can > think of exceptions and normal function returns as well- > behaved value-passing gotos. but nobody wants to ignore > intermediate types in function chaining. so why should > only the functional but not the exception behaviour be > constraint by types? the only difference between exceptions > and function types is that > > * for exceptions, the normal case is that we ignore the exception, > i.e., all we do is pass it on, without touching it. > > * for functions, the normal case is to take the returned value > and do something with it. 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. In my own code (Felix) I am systematically changing which exceptions report errors -- initially I just called Failure. Now I call exceptions that report source code locations... but this isn't really a change in the type of the function throwing such an error. > i always wonder if problem would simply disappear with more > expressive typing systems that allow concise specification > of the normal case for exceptions -- where an piece of code is > just a conduit for exceptions -- and appropriate grouping of > exceptions, for example by subtyping. 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). We can actually do this now, sort of, using classes: class float_not_zero x = if x <> 0 then v := x else raise Invalid_argument sort of thing. However, it is expensive (the best way to test if a matrix is singular is to invert it .. so what constraint can the inversion function have?) and it is generally TOO restrictive to want to transmit through the type system algebraically. Normally, if you think it is important enough you'd use a class to create a new type. ------------------- 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