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 BAA22027; Sun, 10 Jun 2001 01:10:07 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 BAA22081 for ; Sun, 10 Jun 2001 01:10:05 +0200 (MET DST) Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f59NA4P12140 for ; Sun, 10 Jun 2001 01:10:04 +0200 (MET DST) Received: from dylan (1Cust210.tnt3.tucson.az.da.uu.net [63.11.144.210]) by tisch.mail.mindspring.net (8.9.3/8.8.5) with SMTP id TAA24028; Sat, 9 Jun 2001 19:09:55 -0400 (EDT) Message-ID: <001501c0f139$9ce86640$210148bf@dylan> From: "David McClain" To: "Brian Rogoff" Cc: References: Subject: Re: [Caml-list] Evaluation Order Date: Sat, 9 Jun 2001 16:12:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > No, if Hebrew or Arabic were your native tongue you'd have exactly the > same expectation as you have now, which is that the events occur in the > order that you scan them while reading. What happens in OCaml now is like > some weird boustrophedon. Huh? Hebrew and Arabic read from right to left, which is why I said what I did... A boustrophedon infers that the order changes to and fro in a raster pattern. I won't argue the point about unspecified order of evaluation. I would argue for notation that indicates temporal preferences and helps to enforce them in the code. > Use lots of lets to sequence operations. Avoid side effects like output in > value returning operations, otherwise you'll want to use lets to sequence > the outputs while getting the value. Write Haskellish code, by which I > mean try to push all of your refs and mutable values to the top level and > have all of your library calls pure. Agitate to get this annoying feature > fixed. Etc... Actually the side effects I was referring to have nothing to do with reference vars. In fact there are none in the code. Rather, the side effects have to do with the order in which data are processed and sent along to the next job upstream. I would argue for something stronger here. The mistake was made as a result of performing a commutative arithmetic operation between two results that should never commute in time. I think a sequencing operation and a type that distinguishes objects that have specified temporal orderings is in order here. Otherwise we are left to astute programmers who have to be on their very guard continuously against unintentional misuse of evaluation order. Humans are not trustworthy in the sense that machines are, which never tire of mundane tasks. - DM ------------------- 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