Re: [Caml-list] Evaluation Order

[Dave Mason <dmason@sarg.Ryerson.CA>]

There is a solution to this problem.  I don't know if anyone has
proposed this before, but it would be hard to believe that it's novel.

The idea is to annotate the type of any functional result with the
fact that it has escaping side-effects.  Then to not let any
so-annotated value be used directly in an expression.  Let's look at
David's problem:

>>>>> On Sat, 9 Jun 2001 16:28:56 -0700, "David McClain" <dmcclain1@mindspring.com> said:

> My mistake was writing

> let ans = process_stream() + process_tail()

In what I'm proposing, the result type of both process_stream and
process_tail would be so annotated:
	process_stream : unit -> int effect
	process_tail   : unit -> int effect
and the compiler would give you a side-effect error with that
expression.  But using such a value which was a simple variable would
remove the annotation and apply it to the whole expression, so:

	let ans =
	 let ans1 = process_stream() in
	 let ans2 = process_tail() in
		ans1 + ans2

would work.  Note that the function containing this computation must
also be tagged as side-effecting when its results are used elsewhere.

This would be fairly easy to add to the compiler and would *not*
require us to have a specified execution order in expression
evaluation (a Good Thing(TM)) but would prevent you from making the
kind of error seen here.  The biggest problem is that this is not a
proper type, as I have described it, although it could go in the
module interfaces as such, and can be automatically propagated by the
compiler.

So then David could go back to trusting the ocaml type system to
protect him.  :-)

This would not be completely backward-compatible with existing ocaml
programs (a Bad Thing(TM)), but any programs that it would break would
be ones that currently depend on the existing evaluation order (a Very
Bad Thing(TM)), so forcing them to fix their programs would be a Good
Thing, and for a change, two wrongs would make a right!

> What is needed is some specification that indicates temporal
> preference, and then the type checking mechanism must be enhanced to
> keep temporal order.  Most programs in OCaml probably have no
> preference, and in fact, a sense of order is strongly discouraged in
> most FPL's -- e.g., Haskell.

I have a feeling that what I propose is somehow related to monads, but
in a way that ocaml programmers would not find intrusive and would
make our programs more robust.

(This could actually be made a little more more useful at the cost of
being a little more complex.  Instead of 'a effect, have at least
three annotations: 'a ref_effect, 'a io_effect, 'a assign_effect.  So
the types of some common operators would be:
	(:=) : 'a ref -> 'a -> unit assign_effect
	(!)  : 'a ref -> 'a ref_effect
	incr : int ref -> unit assign_effect
	printf : ('a, out_channel, unit) format -> 'a io_effect
Then you could have any number of ref_effects combined with at most
one io_effect, but assign_effects could not be combined with another
assign_effect, more than one io_effect, or any ref_effects.  This
would break a minumum number of existing programs, but still be safe.)

../Dave
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr