From ... From: Erik Naggum Subject: Re: That place.. (was: How to make a mutually recursive macro and function) Date: 2000/03/06 Message-ID: <3161299902310489@naggum.no>#1/1 X-Deja-AN: 593648047 References: <38BD0685.5DBB2389@iname.com> <38BE9543.5D65CF29@iname.com> <38BFA000.FE6D8056@iname.com> <38C00DBF.ED8CF15@iname.com> <38C271A2.F5C6D7B8@iname.com> mail-copies-to: never Content-Type: text/plain; charset=us-ascii X-Complaints-To: newsmaster@eunet.no X-Trace: oslo-nntp.eunet.no 952312174 3058 195.0.192.66 (6 Mar 2000 03:09:35 GMT) Organization: Naggum Software; vox: +47 8800 8879; fax: +47 8800 8601; http://www.naggum.no User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5 Mime-Version: 1.0 NNTP-Posting-Date: 6 Mar 2000 03:09:35 GMT Newsgroups: comp.lang.lisp * Christopher Browne | What it *really* says is that Scheme has some significant differing | underlying assumptions from Common Lisp. we all know this to be a deep and fundamental truth, already. | b) The "call/cc thing" parallels the "tail recursion thing" where | Scheme requires that implementations have some common primitives. | CL requires no such thing, which provides implementors greater | flexibility, but which diminishes some of the expectations on how | things work that can be made with Scheme. this is also one of the differences between the Scheme and the Common Lisp communities. the Scheme community uses the specification as the source for its expectations and when it can't find something in the specification for Common Lisp, claims that Common Lisp cannot expect it. the Common Lisp community uses the specification and the common sense of vendors and the functioning of the market as its source of expectations, and consequently doesn't have a problem with any of the things that Scheme people have problems with in Common Lisp. on the other hand, the Common Lisp community recognizes the Scheme community's need for its very thin specification, and argues that the Scheme community cannot expect to have any useful functions in a Scheme environment at all, to which the Scheme community always responds that every Scheme implementation has a lot of goodies that you can rely on, and then there's slib and whatnot, so in the end it seems rather specious of the Scheme adherents to argue that the Common Lisp community cannot expect tail-call merging, which every implementation offers given sufficent optimization settings. | c) The *problem* with Scheme (which the SRFI process may help remedy) | that the "call/cc" thing shows off is that call/cc was intended to | be treated as a *primitive* that would be used to implement control | structures. and Common Lisp has all those control structures that Scheme people implement with call/cc. it's like giving programmers access to a primitive of creating, linking, and unlinking call frames, but no function call primitive. (Scheme doesn't have funcall, as you know. :) | In short, it's not that call/cc is particularly bad, it's that call/cc is | merely a primitive, and isn't widely useful until you use the primitive | to build specifically useful structures. which implies that the usefulness of implementing these control structures with call/cc has to be questioned, since none of the Common Lisp implementations even use the primitive operation call/cc underneath, and they also don't generally heap-allocate call frames, but remain with the stack-allocation paradigm. in short, call/cc is a primitive that is too primitive for its own good: it demands a particular way to do things that doesn't reflect how people have come to conclude they should be done. the same is true of Scheme's tail calls. it doesn't make sense to force every tail call to be a jump, as it messes with argument passing conventions and stack unwinding and many forms of debuggability and a host of other issues tha makes communication with other languages hard. so in my view, Scheme's core function call model is simply a mistake, and both tail calls and call/cc make the design mistakes explicitly visible to the users. learning from such mistakes is an important part of moving forward in language design, and this may indeed be why no other language has picked up on these ideas, despite having picked up on a number of other valuable contributions from Scheme. some of this reflects badly on "adjacent ideas" in Scheme, too. again in my view, there are probably mistakes in Common Lisp's design that makes it hard for people to pick up on adjacent ideas, too. for one thing, I have started to believe that the use of upper-case symbol names is a serious communications bottleneck with other languages that we need to talk to these days. it's not that we can't overcome it, it's that it's such a hassle to overcome it. and it's not a technical issue, just like start-up time is not a technical issue, it's a matter of perception and how we approach contrary views when they necessarily come up. #:Erik