Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
[Caml-list] Evaluation Order
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2001-06-11 (17:56)
From: Dave Mason <dmason@s...>
Subject: Re: [Caml-list] Evaluation Order
>>>>> On Mon, 11 Jun 2001 00:06:29 +1000, John Max Skaller <> 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.

Bug reports:  FAQ:
To unsubscribe, mail  Archives: