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 NAA08757; Mon, 11 Jun 2001 13:23:12 +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 NAA09000 for caml-list@pauillac.inria.fr; Mon, 11 Jun 2001 13:23:11 +0200 (MET DST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA29701 for ; Sun, 10 Jun 2001 19:27:16 +0200 (MET DST) Received: from sarg.Ryerson.CA (sarg.ryerson.ca [141.117.18.117]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id f5AHRFL00708 for ; Sun, 10 Jun 2001 19:27:15 +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 NAA09290; Sun, 10 Jun 2001 13:27:08 -0400 Message-Id: <200106101727.NAA09290@sarg.Ryerson.CA> To: caml-list@inria.fr cc: John Max Skaller , David McClain , Brian Rogoff Subject: Re: [Caml-list] Evaluation Order In-reply-to: Your message of "Sun, 10 Jun 2001 09:47:25 PDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Sun, 10 Jun 2001 13:27:08 -0400 From: Dave Mason Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk >>>>> On Sun, 10 Jun 2001 09:47:25 -0700 (PDT), Brian Rogoff said: > Well, OCaml isn't referentially transparent, and it is strict to > begin with. I agree that it would be awful if my argument was only > about the order of evaluation of (+). No it isn't. But it would be nice if code which wasn't was detectable as such and otherwise you could reason as if it were. I have a longish email on its way to the list that proposes marking the results of any functions that cause side-effects as such, and not allowing them to be used in compound expressions where they would be order-dependent. > Why not make the default correspond to everyone's intuition? Because that isn't everyone's intuition! Better to not specify the order, but prevent expressions where order dependency could create a problem. That also leaves the compiler maximum flexibility in ordering evaluation (while this may not be exploited by the current compilers, it is likely to become increasingly important as the processor/memory differential increases). > I agree completely. I even shove in prints to debug purely > functional code (shame on me!) by adding "let _ = prerr_endline > ... in" in such constructs. I sometimes do that. Perhaps for my proposal it would be useful to have a ``debugf'' that prints (and flushes) to stderr, but isn't flagged as side-effecting, with the assumption that these are not part of the semantics of the program and will be removed before production. (BTW, my postings to this list usually take 2 days to appear... I just checked and this machine's mail queue is empty, so I don't know which machine is holding on to my posting.... but I wish it would stop!) ../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