From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsmi-us.news.garr.it!newsbo.news.garr.it!newsrm.news.garr.it!NewsITBone-GARR!news.mailgate.org!newsfeed.icl.net!newsfeed.wirehub.nl!newsfeed00.sul.t-online.de!t-online.de!newsfeed.esat.net!nslave.kpnqwest.net!nloc.kpnqwest.net!nmaster.kpnqwest.net!nreader1.kpnqwest.net.POSTED!not-for-mail Newsgroups: comp.lang.lisp Subject: Re: Why is Scheme not a Lisp? References: <87pu28kzjy.fsf@charter.net> <87eliokv9v.fsf@charter.net> <87sn73c40c.fsf@charter.net> Mail-Copies-To: never From: Erik Naggum Message-ID: <3225233908428331@naggum.net> Organization: Naggum Software, Oslo, Norway Lines: 158 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 16 Mar 2002 02:18:17 GMT X-Complaints-To: newsmaster@KPNQwest.no X-Trace: nreader1.kpnqwest.net 1016245097 193.71.199.50 (Sat, 16 Mar 2002 03:18:17 MET) NNTP-Posting-Date: Sat, 16 Mar 2002 03:18:17 MET Xref: archiver1.google.com comp.lang.lisp:29132 * William D Clinger | Yes, you are. I was talking about the fact that the defining feature of | Lisp2, separate environments for values and for functions, creates a bias | against higher-order thinking. No, it does not. This is completely bogus reasoning. And if it is your gripe with funcall, which seems to be a standard problem for Scheme freaks, even though they have _apply_ just as Common Lisp does, I have posted a macro called "with-functions" that effectively removes the funcall from sight and declares the variables as functions. This should shift the bias back in the favor of "higher-order thinking". That macro took me seven minutes to write, debug, and test (,', always confuses me). The distance between a Common Lisp and "higher-order thinking" is thus seven minutes of my time, and a google search and cut-and-paste for you. Please quit griping about this non-existing problem. | In Lisp2, functions are usually bound in a different environment from | other values, so Lisp2 programmers do not think of functions simply as | values. This sounds totally bogus. It certainly does not follow from the premise. | Thus, for example, you can find examples of Common Lisp programmers who | do not see the need for hygienic macros, claiming that function names | cannot be shadowed. You can find examples of absolutely anything, and if you include jails and mental hospitals, even more, so this must be the weakest of all possible ways to express a criticism. It probably surprises you to learn that symbols in the common-lisp package cannot be defined or bound in a conforming program, so it is actually _true_ that "function names cannot be shadowed" (which is a very strange way of saying it. but I can sort of reverse-engineer the proper meaning from it). At least a macro can expect the standard environment to apply, and I believe macros should do just that, and if they require additional environments, they should use symbols in a package over which the macro author has control. Because of packages and the restrictions on using symbols in the common-lisp package, there is no need to ensure that you have the right definition of any symbol in the common-lisp package with a function definition. This, if you bind a variable "list" in Scheme, you have clobbered the standard function "list" for the body of the form that binds it, but if you try to name a local function "list" in Common Lisp, you already have an error in your program, one that a compiler should be reporting to you. | Are they unaware of FLET and LABELS? Probably not. Probably they're | just aware that FLET and LABELS are so seldom used as not to cause a | problem for macro writers. Are you unaware of the restrictions on symbols in the Common Lisp package? If you are, please see ANSI X3.226-1994 11.1.2.1.2. | Why aren't FLET and LABELS used? There are many reasons, but one is the | cultural bias against higher-order thinking that results from a Lisp2. Nonense. It does not result from a Lisp-2 at all. That is just a stupid argument that Scheme freaks like to offer, and it is so goddamn _stale_. | If you still don't get it, consider what it is like to simulate higher | order functions using function objects in Java. To call a function | object f, you use a special syntax such as f.call(_) instead of writing | f(_). The .call can be viewed as a kind of cast that coerces from the | value domain to the function domain. Common Lisp's FUNCALL can be viewed | as a similar coercion. HELLO!? I PUBLISHED A MACRO THAT REMOVED FUNCALL FROM VIEW SO THAT YOU FUCKING OBNOXIOUS SCHEME FREAKS NO LONGER HAVE ANYTHING TO WHINE ABOUT! YOU MORONS HAVE SPENT *YEARS* WHINING ABOUT THIS, YET IT TOOK ME NO MORE THAN SEVEN MINUTES TO GET RID OF IT AND CONFLATE THE NAMESPACES FOR A SPECIFIC LIST OF VARIABLE NAMES. What does this show, _other_ than that Scheme freaks are _much_ more interested knocking and denigrating Common Lisp than doing anything useful and constructive? If you still do not get it, figure out that Common Lisp has the power and capacity to change its syntax so it can accomodate such perversely anal- retentive needs as removing an operator from sight (even though you _still_ need apply). | Many of the people who are attracted to Lisp in the first place don't | like to clutter their programs with all these injections and coercions | from one type to another. If they had anything approaching a usable intelligence, they would figure out how to write the macro I wrote, and I did not even have a problem with funcall to begin with, I was just so goddamn tired of the useless, incompetent whining from people who were so clueless they could not even write a little macro to get what they wanted. | They're annoying and unnecessary. No, this is a conclusion about Common Lisp drawn from Scheme premises. Common Lisp is not a dialect of Scheme. This is _precisely_ what this is all about. You Scheme freaks are so full of yourself that you cannot even see that other people are _able_ to make other design choices than you have. You think everything other people do is _wrong_, do you not? Some of you guys sure act like you have a one-bit right/wrong flag, and of course you do nothing wrong, so therefore what other people do must be _wrong_, since it is not what you do, and what you do is _right_. Common Lisp programmers do not regard this the same way you do. _If_ they do, they write something like the macro I wrote. There _is_ no problem to a Common Lisp programmer -- a beginner would ask if it could be fixed and an experienced Common Lisp programmer would just do it. It is _only_ a problem to Scheme freaks who have a grudge against Common Lisp and want to confirm their delusions of superiority to themselves. | If you're a first- or second-order thinker, then you probably won't agree | with this, and you'll be happy with a Lisp2. If you're a higher-order | thinker, you'd be happier with a Lisp1 if all else were equal. Lisp-1 and Lisp-2 have nothing whatsoever to do with this issue. Even funcall is a non-issue. What matters is probably what Kent Pitman has been hinting at: People who want a one-bit universe where purity and elegance and such follow very simple rules are much more attracted to functional programming languages _and_ Lisp-1. You have the causality all wrong, here, and this is quite obvious: People are not _naturally_ "higher-order thinkers", but there is much evidence to support a view that some people have a hard time dealing with "horizontal complexity" and much prefer "vertical complexity" on very small initial space. These two types are fairly incompatible. A vertical complexity guy will look at a horizontal complexity guy and think he is not superskilled in anything and therefore untrustworthy and useless (many academics fall into this trap), whereas a horizontal complexity guy who meets a vertical complexity will be stunned how little he knows about the world about some corner of which he has this astonishing amount of knowledge. Now, the most interesting thing happens is when they meet one of their own type: A vertical complexity guy will trust another and defer authority to him automatically in his "area", thinking (1) that he, too, has spent a lifetime in some incredibly small area, and (2) that you cannot go wrong if you study something long enough, especially not if some accredited university has granted him a degree. However, those who master horizontal complexity much more easily, generally display an amazing amount of insight and knowledge in many areas, draw analogies from all kinds of areas, and they can communicate with others who master horizontal complexity with ease and can understand, not trust, those who have more knowledge in one area than another, because their knowledge is integrated into a system intended to mirror the world they experience. The vertical complexity guys have built their "system" from axioms and theorems that others have provided, before they may be able to provide their own deep insight into something that requires extremely specialized skills to appreciate. I suspect that functional programming (and Scheme) appeals to those who find that they master vertical complexity more easily and dynamic programming (and Common Lisp) appeals to those who find that they master horizontal complexity more easily. However, this is _NOT_ (repeat: NOT) a one-bit flag in your personality. But, *sigh*, what's the use? One-bit people are going to respond as if it is, as I have I created but two pigeonholes and want to stuff all of mankind into one of them, anyway. /// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.