Path: utzoo!attcan!uunet!husc6!think!ames!amdahl!pyramid!prls!philabs!micomvax!mosart!marc From: marc@mosart.UUCP (Marc P. Rinfret) Newsgroups: comp.lang.lisp Subject: Re: What's the value of lexical scoping? Keywords: Scope, Binding, Locals, Break, Future of LISP Message-ID: <330@mosart.UUCP> Date: 14 Jun 88 14:28:06 GMT References: <24508@ucbvax.BERKELEY.EDU> <515@dcl-csvax.comp.lancs.ac.uk> Reply-To: marc@mosart.UUCP (Marc P. Rinfret) Organization: Silicart Inc., Vaudreuil QC Lines: 91 Summary: In article <515@dcl-csvax.comp.lancs.ac.uk> simon@comp.lancs.ac.uk (Simon Brooke) writes: >In article <24508@ucbvax.BERKELEY.EDU> mkent@dewey.soe.berkeley.edu (Marty Kent) writes: >>I've been wondering lately why it is that "modern" lisps like Common Lisp >>and Scheme are committed to lexical scoping. > >Good! somebody else prepared to stand up and say Common LISP is a mess. I think you are jumping the gun. Wondering about a feature of a language and saying it "is a mess" are two different things. >... >Finally, if you (or your employer) have a wallet as >deep as the Marianas trench, there's the much-heralded micro-explorer. >That *ought* to give a decent LISP environment, but again I haven't seen >one. I haven't seen one but I understand it gives you pretty much the same environment as the one you get on the Explorer (or the Lambda). This is real good system, and yes it does support lexical scoping. And yes it also keeps the names of the local variables around, and yes it has a good debugger. >>2) while it's true that Common Lisp's scoping makes it difficult to write >>debuggers, lexical scoping is still a good trade-off because it buys >>you... >> Ok, tell me how many of us will have the pleasure of WRITING a debugger? You cannot assess the value of a language by how easy or hard it is to write a debugger. A language is good if you can easily develop code, a good debugger is good to have but this is a feature of the implementation. If the system you have doesn't include one that's bad, go get a good one now. If you are developing your system it is worth the additional effort, but then you don't have to design the debugger on top of the implementation you make it a part of it. >We had a long discussion about this on the uk.lisp newsgroup. I still have >much of this on file and could post it if people are interested (I can't >easily mail to the States). Sure post. >Advocates of lexical scoping offered a number >of extremely tricky programming examples which couldn't be done with >anything else. These were very impressive *as tricks*, but I couldn't ever >imagine using any of them in a serious programming situation. In short, I >wasn't convinced - but I should add that I didn't convince anyone else >either. The question here is not what feature enables you to pull the best tricks, but to have the language play the less tricks on you. I believe that accidental dynamic capture of identifiers is a dirty trick. It makes for hard to find problems. >... >the good news is that it appears that dynamic binding a la EuLisp will be >incorporated Common Lisp as it is currently defined DOES incorporate dynamic bindings, you simply have to ask for it. (DEFVAR ...) I think it is nice to have the choice of both. One of the nice things about having lexical binding be the default is (on top of preventing accidental shadowing) that it enable the compiler to warn you when you use an undeclared variable (pretty often a typo, that with full dynamic would only be detected at runtime). Unless you don't like to declare variable then you may as well use F......! > and there will be no packages. The Package system of Common Lisp is something that no one likes, but you do need something like it if you are to develop any decent size system. I don't know the kind of projects you have been involved with but when you work on a large (> 25 man years, with people coming and going), you need something to manage your namespace. Saying "no packages" is not good enough, do you have any ideas how to replace it? >Obviously, I have my ideas about what a good LISP looks like (all right, >as a minimum it has dynamic binding, both LAMBDA and NLAMBDA forms, at >least the option of non-intrusive garbage collection; although it allows >macros, there is nothing you can't do with a function; and it does not >have packages, PROG, GO, stupid tokens in parameter lists, SETF....) - So what's your problem with CL. It has all you want, the features you don't like you simply don't use. If LISP is to be more than an academic toy or a philosophical statement it must include some "impure features". If you want to stay pure, keep away from these. I have never personally used PROG and GO but I've seen cases where they were well used. SETF is something real nice, it is based on an easy to grasp concept. It reduces the namespace cluttering (nice when you don't like packages!), you don't have to look around to figure out the name of the modifier function (provided you know the accessor). Again this is something you may better appreciate when you're working with large systems.