Re: [Caml-list] GC and file descriptors

[skaller <skaller@ozemail.com.au>]

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