Re: [Caml-list] Evaluation Order

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

>>>>> On Mon, 11 Jun 2001 00:06:29 +1000, John Max Skaller <skaller@ozemail.com.au> said:

> In principle, the Felix type checker would prevent this:
> side-effects are not permitted in functions.

> 	The reason for relaxing the rules is that it is very ugly and
> insecure to write things like:

> 	val x : int; // uninitialised variable!
>	fetch(&x,&state_object);

> instead of

> 	val x : int = fetch(&state_object);

> I can't think of good way around this though.

Functions *should* be able to do side-effects (unless you have a pure
functional language), or at least, there need to be chunks of code
that can have side-effects and also return values.  Otherwise you
can't write atomic code in a multi-threaded environment - i.e. pull
the next thing off a queue (unless you pass in refs as you suggest,
which I really dislike).

I think my proposal from the weekend is better: functions can have
side effects, but you can't use the results in a way that will bite
you (due to order of evaluation).

> You can also cheat, by wrapping C functions as Felix functions:
> there's no way to check if the C function has side effects or not.

You can always cheat by stepping outside the semantics.  Write in
assembler, edit the executable with Emacs, etc.  The last system I am
aware of where you couldn't cheat was the Burroughs operating system
from the 1970's, where only the system linker could produce executable
programs.  But even there, I'm sure there was a cheat available to the
system architects.

../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