Path: utzoo!yunexus!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!dali!rpi!uupsi!sunic!sics.se!sics!bjornl From: bjornl@tds.kth.se (Bj|rn Lisper) Newsgroups: comp.lang.functional Subject: Re: Laziness and Back-to-front Lists Message-ID: Date: 29 May 90 14:58:42 GMT Article-I.D.: pike.BJORNL.90May29165842 References: <14531@dime.cs.umass.edu> <2535@skye.ed.ac.uk> <8691@cs.utexas.edu> <4170@castle.ed.ac.uk> <3738@moondance.cs.uq.oz.au> <4289@castle.ed.ac.uk> Sender: news@sics.se Organization: The Royal Inst. of Technology (KTH), Stockholm, Sweden. Lines: 30 In-Reply-To: aipdc@castle.ed.ac.uk's message of 28 May 90 21:28:32 GMT In article <4289@castle.ed.ac.uk> aipdc@castle.ed.ac.uk (Paul D. Crowley) writes: %WARNING: Uninformed opinions ahead! %I was under the impression that in a truly "pure" functional language %the problem doesn't arise because nothing has more than one argument. %Things that look as if they should have more than one argument are dealt %with lambda-calculus style: %2+3: ((plus 2) 3) %(plus 2) means plus applied to two, and equals a function which adds two %to its argument. %so ((plus 2) 3) = (plus2 3) = 5 %Under these circumstances you _expect_ order of arguments to be %significant, so it doesn't surprise you that you get different results %if you change it. Yes, this is exactly the "problem" with lazy functional languages as I see it: they rely on a serial evaluation order of arguments obtained from the currying of functions in order to get unary functions only, as in lambda calculus. HOWEVER, this ordering is an imposed, arbitrary one. As I understand it this is inherent in the lambda calculus itself. So, there's a problem with the very theoretical foundations of functional programming! My last comment is deliberately provocative. It would be interesting to hear any comments on it from people more involved in the field than me. Bjorn Lisper