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 NAA08201; Mon, 11 Jun 2001 13:19:20 +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 NAA08225 for caml-list@pauillac.inria.fr; Mon, 11 Jun 2001 13:19:20 +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 DAA22745 for ; Sun, 10 Jun 2001 03:04:26 +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 f5A14PP15627 for ; Sun, 10 Jun 2001 03:04:25 +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 VAA32072; Sat, 9 Jun 2001 21:04:19 -0400 Message-Id: <200106100104.VAA32072@sarg.Ryerson.CA> To: "David McClain" cc: caml-list@inria.fr Subject: Re: [Caml-list] Evaluation Order In-reply-to: Your message of "Sat, 09 Jun 2001 16:28:56 PDT." <000901c0f13b$f981c610$210148bf@dylan> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sat, 09 Jun 2001 21:04:19 -0400 From: Dave Mason Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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" 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