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 BAA22189; Sun, 10 Jun 2001 01:26:54 +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 BAA22283 for ; Sun, 10 Jun 2001 01:26:53 +0200 (MET DST) Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id f59NQqP12236 for ; Sun, 10 Jun 2001 01:26:52 +0200 (MET DST) Received: from dylan (1Cust82.tnt8.tucson.az.da.uu.net [63.15.233.82]) by hall.mail.mindspring.net (8.9.3/8.8.5) with SMTP id TAA05728 for ; Sat, 9 Jun 2001 19:26:46 -0400 (EDT) Message-ID: <000901c0f13b$f981c610$210148bf@dylan> From: "David McClain" To: References: <001501c0f139$9ce86640$210148bf@dylan> Subject: Re: [Caml-list] Evaluation Order Date: Sat, 9 Jun 2001 16:28:56 -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 > > 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. In fact let me be a bit more specific, by way of example... The block convolution operation could be viewed as adding reverberation to a data stream. The first function processes the entire stream. The second operation writes out the remainder, the reverb tail, after the input stream has been exhausted. My mistake was writing let ans = process_stream() + process_tail() where both operations return a count of how many data samples had been written to the output stream. I accidentally got the tail processing first, which caused the anomalous output. The front of the output stream had too much null data, and the final tail of the stream was chopped off. The results of these two operations, integers, are arithmetically commutable under addition. But what isn't commutable is the order in which these operations occur. No current type checking in OCaml (or any other language with which I am familiar) could help catch this mistake. 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 am saying that real-world applications for control systems do have strong needs for these additional constraints. I am not being critical of OCaml or any other language here. But my experience pointed out the need for even more from programming languages than what we have today. The major flubs of the past decades, Arianne, Therac, and many others, are examples of systems in which not only the data types have to be ensured, but also temporal orderings of function evaluation. We are rapidly adopting a system with a foundation of dust when we come to rely so heavily on human programmed computers to manage and treat our lives. - DM ----- Original Message ----- From: "David McClain" To: "Brian Rogoff" Cc: Sent: Saturday, June 09, 2001 4:12 PM Subject: Re: [Caml-list] Evaluation Order > > 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 ------------------- 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