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 RAA24329 for caml-red; Wed, 8 Nov 2000 17:21:51 +0100 (MET) 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 AAA03794 for ; Tue, 7 Nov 2000 00:19:20 +0100 (MET) Received: from ftp.filemaker.com (ftp.filemaker.com [192.35.50.27]) by concorde.inria.fr (8.11.1/8.10.0) with ESMTP id eA6NJI119843 for ; Tue, 7 Nov 2000 00:19:19 +0100 (MET) Received: from imap.filemaker.com (imap.filemaker.com [17.184.4.101]) by ftp.filemaker.com (8.9.0/8.9.0) with ESMTP id PAA27695 for ; Mon, 6 Nov 2000 15:19:15 -0800 (PST) Received: from [17.184.5.111] ([17.184.5.111]) by imap.filemaker.com (8.9.3/8.9.0) with SMTP id PAA15447 for ; Mon, 6 Nov 2000 15:19:17 -0800 (PST) Message-Id: <200011062319.PAA15447@imap.filemaker.com> Subject: Re: practical functional programming Date: Mon, 6 Nov 2000 15:24:41 -0800 x-sender: hao-yang_wang@mail.filemaker.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Hao-yang Wang To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: weis@pauillac.inria.fr >Haskell is a lazy language, with which we are supposed to ignore when (or >whether) an expression is going to be evaluated, at least most of the >time. As the result we have to give up all the side effects (i.e., I/O and >destructive data updates), because we have no idea on the order in which >these side effects occur. On the other hand, the ML family is strict. People who complain that o'caml does not have a fixed evaluation order on function arguments should take a look at Haskell, things are much worse there. :-) Hao-yang Wang