]> > What alternatives are there? > > One is to have exception specifications on functions, > but that is known not to work very well. The first > difficulty is that once you have them, they must > become part of the type system. They then 'snowball' > through the whole program (in the same way 'const' > does to C programs). but isn't this snowballing exactly what you want? 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. 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. 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