From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA28814 for caml-red; Wed, 11 Oct 2000 21:53:39 +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 OAA23231 for ; Wed, 11 Oct 2000 14:22:47 +0200 (MET DST) Received: from opus.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by concorde.inria.fr (8.10.0/8.10.0) with ESMTP id e9BCMkb00693 for ; Wed, 11 Oct 2000 14:22:46 +0200 (MET DST) Received: by opus.cs.cornell.edu with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Oct 2000 08:22:45 -0400 Message-ID: <706871B20764CD449DB0E8E3D81C4D43BFCA36@opus.cs.cornell.edu> From: Greg Morrisett To: "'Hendrik Tews'" Cc: caml-list@inria.fr Subject: RE: Undefined evaluation order Date: Wed, 11 Oct 2000 08:22:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: weis@pauillac.inria.fr > I would like to vote for leaving the evaluation order > unspecified (implicitly repeating all suitable arguments from > previous postings). The specification should only regulate the > necessary things not more. I don't see why. As far as I can tell, the only reason to not specify the order is for performance. I've never seen a systematic study that significant performance gains are achievable across a range of applications. Most compilers only do very local re-orderings, and these can typically be achieved with local effects analysis (at least for languages like ML that are relatively effect free.) We've heard promises of expression-level parallelism since the dawn of Fortran and Lisp. But for 40 years, they speedups have yet to be realized because the granularity is always too small to do the necessary synchronization for multi-processors, and the granularity is too large for instruction-level parallelism (i.e., other hazards manifest.) If you truly believe that magic compilers will someday come along and parallelize things, then why are you worried that these compilers will be stopped by a specified evaluation order? IMHO, there are compelling reasons to at least specify an evaluation order, if not to standardize on left-to- right. In spite of the fact that programmer's *should* realize that expressions could be evaluated in any order, they tend to assume the order that the current compiler uses. Then when someone else ports the code, or the compiler changes, things break. As I mentioned earlier, when teaching, it's nice for a language to be simple and uniform. Explaining to a student why: let x = input() in let y = input() in (x,y) is not equivalent to: (input(), input()) is one more thing that confuses them -- especially when we emphasize that the whole point of anonymous functions is to avoid naming things that need not be named! A standard trick for Scheme coders is, as someone suggested, to randomize the order of evaluation in the hopes of tripping across such bugs. Ugh. Maybe the type-checker should just randomly type-check a few expressions too :-) If you're going to have an unspecified order of evaluation, then I think you realistically need an effects analysis in order to warn the programmer that what they are writing is dependent upon the order. Unfortunately, either the analysis would need to be global (to get rid of all the false positives) or else you'd have to augment function types with effects information, add in polymorphic effects, etc. In other words, you're buying into a whole ball of wax. Neither option seems all that wonderful. -Greg