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 NAA05846 for caml-red; Thu, 12 Oct 2000 13:48:23 +0200 (MET DST)
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 NAA05023 for <caml-list@pauillac.inria.fr>; Thu, 12 Oct 2000 13:32:32 +0200 (MET DST)
Received: from opus.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8])
	by nez-perce.inria.fr (8.10.0/8.10.0) with ESMTP id e9CBWVf18599
	for <caml-list@inria.fr>; Thu, 12 Oct 2000 13:32:32 +0200 (MET DST)
Received: by opus.cs.cornell.edu with Internet Mail Service (5.5.2650.21)
	id <S5610XCV>; Thu, 12 Oct 2000 07:32:31 -0400
Message-ID: <706871B20764CD449DB0E8E3D81C4D43BFCA48@opus.cs.cornell.edu>
From: Greg Morrisett <jgm@cs.cornell.edu>
To: "'Dave Berry'" <dave@kal.com>, caml-list@inria.fr
Subject: RE: Undefined evaluation order
Date: Thu, 12 Oct 2000 07:32:30 -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

> May I toss in a possible complication?   I'm thinking of 
> numeric code, and
> the possibilities of optimisation.  

I'm not saying that you can't get better performance
if you leave things unspecified.  Rather, a programmer
might like to know whether they'll get 0 or NaN (or
an exception) rather than "I'll get one of those things
real fast" :-)

Perhaps a practical solution would be to have a flag
controlling whether or not evaluation order is fixed.
Speed demons can turn the flag off, teachers can leave
the flag on.  

It wouldn't be that hard to implement, either -- leave
the compiler largely alone, but do an A-normalization
pass introducing explicit let-expressions to force
the evaluation order.  

-Greg