From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA17013; Mon, 11 Jun 2001 19:56:36 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA16896 for caml-list@pauillac.inria.fr; Mon, 11 Jun 2001 19:56:35 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id OAA11798 for ; Mon, 11 Jun 2001 14:59:16 +0200 (MET DST) Received: from sarg.Ryerson.CA (sarg.ryerson.ca [141.117.18.117]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f5BCxFv14672 for ; Mon, 11 Jun 2001 14:59:16 +0200 (MET DST) Received: from sarg.Ryerson.CA (IDENT:dmason@localhost [127.0.0.1]) by sarg.Ryerson.CA (8.9.3/8.9.3) with ESMTP id IAA14288; Mon, 11 Jun 2001 08:59:05 -0400 Message-Id: <200106111259.IAA14288@sarg.Ryerson.CA> To: John Max Skaller cc: David McClain , caml-list@inria.fr Subject: Re: [Caml-list] Evaluation Order In-reply-to: Your message of "Mon, 11 Jun 2001 00:06:29 +1000." <3B237EE5.80622A4C@ozemail.com.au> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Mon, 11 Jun 2001 08:59:05 -0400 From: Dave Mason Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >>>>> 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. ../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