Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sdd.hp.com!decwrl!shelby!bloom-beacon!GARLIC.STANFORD.EDU!mkatz From: mkatz@GARLIC.STANFORD.EDU (Morris Katz) Newsgroups: comp.lang.scheme Subject: Functionality and implicit arg's (call/cc & referential transparency) Message-ID: <9009041833.AA03000@garlic.Stanford.EDU> Date: 4 Sep 90 18:33:24 GMT References: <1990Aug30.164457.26199@rice.edu> Sender: daemon@athena.mit.edu (Mr Background) Organization: The Internet Lines: 32 Date: 30 Aug 90 16:44:57 GMT From: John Gateley Organization: Rice University, Houston References: <583@array.UUCP>, <1990Aug24.212055.8368@nixtdc.uucp>, <1543@anaxagoras.ils.nwu.edu> Sender: scheme-request@mc.lcs.mit.edu In article <1543@anaxagoras.ils.nwu.edu> krulwich@ils.nwu.edu (Bruce Krulwich) writes: > (define ... > ... > (let -loop-name- (... vars ...) > ... > (another-proc ... > (lambda (arg) (-loop-name- arg)) ; success continuation > (lambda () (-loop-name- var)) ; failure continuation > ) )) The question about whether or not the above is functional hinges on one issue - how is the let loop implemented (heap space was mentioned in the article). If it is implemented with a let/set! approach (the normal macroexpansion for letrec), then it is NOT functional. I disagree! If a construct has a functional implementation, any implementation for which there is no operation that can demonstrate that it is not functional is effectively functional. (Sorry about all the negations, but I can't seem to find any better phraseology at the moment.) My interpreter might implement + using side effects for some perverse reason, but that does not necessarily make + an imperative operator. ------------------------------------------------------------------------------- Morry Katz katz@cs.stanford.edu -------------------------------------------------------------------------------