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 LAA20550; Wed, 13 Jun 2001 11:56:16 +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 LAA20564 for caml-list@pauillac.inria.fr; Wed, 13 Jun 2001 11:56:10 +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 TAA07714 for ; Tue, 12 Jun 2001 19:34:53 +0200 (MET DST) Received: from localhost.localdomain (ppp138.dyn146.pacific.net.au [210.23.146.138]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f5CHYlb17801 for ; Tue, 12 Jun 2001 19:34:49 +0200 (MET DST) Received: from ozemail.com.au (IDENT:root@localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.8.7) with ESMTP id DAA08878; Wed, 13 Jun 2001 03:34:11 +1000 Message-ID: <3B265293.D27EA88A@ozemail.com.au> Date: Wed, 13 Jun 2001 03:34:11 +1000 From: John Max Skaller X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dave Mason CC: David McClain , caml-list@inria.fr Subject: Re: [Caml-list] Evaluation Order References: <200106111259.IAA14288@sarg.Ryerson.CA> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Dave Mason wrote: > > 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), My desire is to have a purely functional subsystem. So I would 'say' that functions cannot have side effects. However, Felix has procedures too, which cannot return values. There is a reason for this. Functions execute 'on the stack'. They may not read input or have any side effects. Procedures work by continuation passing. When you call a procedure, it _returns_ control, passing a continuation, which is immediately resumed by the driver. When a request to read input is encountered, control is also returned. The driver then stores a message and resumes the continuation. In other words, the system is event driven transparently. Now see below: > 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). That is what I am looking for. Basically, I want some sugar, so that users can write: val x = f(); but the implementation is actually equivalent to: val x; f(&x); Note that this is implemented like this: switch(pc) { ... ... pc = 2; return new f(&x); case 2: ... So in Felix, it is not a matter of style that procedures returning values cannot be used 'inside' expressions: it would greatly complicate the compiler, because it would have to linearise expression trees 'down to' any procedure call. Currently, expressions are simply replaced by their C++ equivalents, and the C++ compiler can then have a go at optimising them. BTW: I'm currently putting Felix up on sourceforge: http://felix.sf.net -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 checkout Vyper http://Vyper.sourceforge.net download Interscript http://Interscript.sourceforge.net ------------------- 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