Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!sdd.hp.com!hplabs!otter.hpl.hp.com!hpltoad!cdollin!kers From: kers@hplb.hpl.hp.com (Chris Dollin) Newsgroups: comp.lang.scheme Subject: Re: Fixing the order of evaluation. Minimizing the unexpected. Message-ID: Date: 9 Apr 91 07:25:05 GMT References: <9104041629.AA19876@schizo> <9589@star.cs.vu.nl> Sender: news@hplb.hpl.hp.com (Usenet News Administrator) Organization: Hewlett-Packard Laboratories, Bristol, UK. Lines: 28 In-Reply-To: xerox@cs.vu.nl's message of 8 Apr 91 14:30:22 GMT Nntp-Posting-Host: cdollin.hpl.hp.com J. A. Durieux says: ((lambda (a b) -X-) -A- -B-) = ((lambda (b a) -X-) -B- -A-). Or at least it should be. [1] We had a real good reason to give up refential transparency, and for me it would require an (almost) equally good reason to give up the above property (of which I don't know the name). [2] [1] But, in an imperative language, it *already* isn't; never mind the lambda's, the arguments have to be evaluated in *some* order, and different orders may may a difference. So [1] is a lost cause. [2] I think property [1] is just a consequence of referential transparency, which we've already lost. Incidentally, should anyone think I (or Steve Knight) has something against ``functional programming'' - here meaning programming without side-effects, ie, declarative or ``pure'' functional programming - they'd be wrong. I just think that trying to treat an imperative language (here, Scheme) as though it was pure makes life unnecessarily complex. -- Regards, Kers. | "You're better off not dreaming of the things to come; Caravan: | Dreams are always ending far too soon."