Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!dog.ee.lbl.gov!ucbvax!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!star.cs.vu.nl!xerox From: xerox@cs.vu.nl (J. A. Durieux) Newsgroups: comp.lang.scheme Subject: Re: Fixing the order of evaluation. Minimizing the unexpected. Message-ID: <9650@star.cs.vu.nl> Date: 12 Apr 91 19:56:50 GMT References: <9589@star.cs.vu.nl> Sender: news@cs.vu.nl Organization: Fac. Wiskunde & Informatica, VU, Amsterdam Lines: 49 I said: > ((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] Chris Dollin answers: >[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. No. Currently the evaluation order is undefined, so if the meaning of the expressions somehow depend on the evaluation order, they are *both* undefined. If they don't, they are the same. Even more specific: if they depend, each expression represents a collection of meanings. Again, both represent the same collection. In practice, this means that I can automatically rewrite code in this way (e.g. from one Scheme extension to another, or during partial evaluation), and that I am not forced to read code from left to right (which is *not* necessarily the most "natural" way to read code!), >[2] I think property [1] is just a consequence of referential transparency, >which we've already lost. Referential transparency is a sufficient, but not a necessary condition for this property. I think it deserves a name. Perhaps "order freedom"? Actually, I would like even weaker order requirements to be imposed on Scheme: [a] (f (g a) (h b)) may be evaluated in *any* order, e.g. a-b-f-g-h. [b] The body of a procedure is not guaranteed to be executed after all the arguments to the application are evaluated. I realise *some* requirement should remain (while I am not quite sure which exactly), but e.g. a much stronger requirement of stack efficiency can me made if procedures are allowed to "get rid of" their bodies before starting on a (non-tail-recursive) call. E.g. naive append can execute in constant stack space that way. I am not sure whether I want let* to keep its order-retaining nature. Biep.