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 RAA12730; Sat, 9 Jun 2001 17:57:33 +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 RAA12779 for ; Sat, 9 Jun 2001 17:57:32 +0200 (MET DST) Received: from johnson.mail.mindspring.net (johnson.mail.mindspring.net [207.69.200.177]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f59FvUP09842 for ; Sat, 9 Jun 2001 17:57:31 +0200 (MET DST) Received: from dylan (1Cust170.tnt5.tucson.az.da.uu.net [63.11.146.170]) by johnson.mail.mindspring.net (8.9.3/8.8.5) with SMTP id LAA05023 for ; Sat, 9 Jun 2001 11:57:28 -0400 (EDT) Message-ID: <000701c0f0fd$32c88c90$210148bf@dylan> From: "David McClain" To: Subject: [Caml-list] Evaluation Order Date: Sat, 9 Jun 2001 08:59:41 -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 I thought I would share an experience with all of you to solicit your *constructive* comments. I just rewrote my block convolution routine in pure OCaml native compiled along with the inner loop in C/C++. This is necessarily a side effecting program since it must alter the outside world of data. I had a statement in OCaml that went something like this: let ans = fnx () + fny () where both fnx and fny are side effecting closures. I consider myself a very experienced OCaml programmer, and I am so accustomed to getting pristine results from OCaml, that I spent many hours going through my C/C++ code looking for the error. I was getting anomalous output values at the front of my convolution records, but everything else worked just fine. I was convinced something was awry with my C code --- whenever a problem occurs that's almost always where it is -- never in the OCaml code. I had forgotten about the evaluation ordering in OCaml being from right to left. I am aware of the reasons for this, having studied the Zinc paper some time ago. But the tendency to read implicit temporal ordering of operations as left to right is a very strong psychological factor here. The problem, once tracked down, was easily fixed by restating the routine as let ans = fnx() in ans + fny() to force evaluation of fnx before fny. I suppose if Hebrew or Arabic were my native tongue then the opposite expectation would be true and I would have naturally written let ans = fny() + fnx() and I would be no wiser about evaluation order here, since everything would have worked properly. I don't have a good answer to this problem, but I did want to point out the one and only place where OCaml forced me to spend hours debugging a problem caused solely by a clash of psychology and OCaml semantics. All of my other debugging activities have, and will probably continue, to focus on C/C++ as the likely culprit. This problem will be permanently etched into my mind from now on, and I will be sure to remember to avoid order dependent syntax. The same problem occurs regularly in C, and I have become quite accustomed and adept at avoiding these ordering problems. Good examples are to be found among C preprocessor macrology. I just now have to remember that the same is true of OCaml. I had been lulled into a belief that OCaml was nearly perfect, while C/C++ is definitely not. The problem is not one of OCaml, but rather a clash between normal psychological expectations and the programming language at hand. Since embedded realtime systems are chock full of temporally ordered operations this must be one of the severe weak points in software control systems. There must be a better way to guide human thinking here. Just as OCaml has provided a system to look over our shoulders and force us to write the correct things, there must be a way of doing something similar for temporally dependent clauses. Any thoughts? (other than that I was boneheaded here!) - 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