shebs@utah-orion.UUCP (Stanley Shebs) (07/08/86)
There has been some interest in my recent but rather cryptic mention of the Lisp dialect "3-Lisp". 3-Lisp was first defined in Brian Smith's thesis from MIT in 1982 ("Reflection and Semantics in a Procedural Language", MIT LCS TR-272). It's about 500 pages of pretty heavy going, and the Maclisp implementation in the appendix is too full of bugs to be really useful. There are papers by Smith in the 84 POPL in Salt Lake City, and in the 84 Lisp conference, where he and Jim desRivieres show an implementation method. Xerox PARC Intelligent Systems Lab report ISL-1 is the reference manual (it's titled the "Interim 3-LISP Reference Manual, and is also coauthored with Jim desRivieres). I believe there are later manuals from either PARC or CSLI, which is where Smith is at these days. I have an implementation of 3-Lisp that used to work in PSL, but then I translated it to Common Lisp, and as of yet have not gotten the necessary readtable hacking to work yet (3-Lisp requires massive and tricky changes). I hope to have it finished sometime this summer (if I can find the time!). The implementation has been specially hacked to spill its guts while running, since reflection is rather a mysterious process, and one can't really understand it without seeing it in action. However, it is ridiculously slow. A good compiler for 3-Lisp would be very difficult, since reflection requires that one be able to produce, manipulate, and re-install the full state of the virtual machine at any time. stan
jjacobs@well.UUCP (Jeffrey Jacobs) (07/10/86)
In <137@utah-orion.UUCP>, Stan Sheb writes: >I have an implementation of 3-Lisp that used to work in PSL, but then >I translated it to Common Lisp, and as of yet have not gotten the >necessary readtable hacking to work yet So much for the wonderful portability of Common Lisp! To add another story about the wonders of porting to Common Lisp from a Local User's Group meeting of one of the Lisp Machine companies, "I ported a large program from Zeta-Lisp to Common Lisp. After I had it almost working, I decided I'd had enough. I wouldn't use the Common Lisp version". The person telling this story shall remain nameless, but definitely knows what s/he is doing... For those who have been unable to understand some of my points about Common Lisp and how it SHOULD have been done, see the EuLisp/ISO draft standards! -Jeffrey M. Jacobs, CONSART Systems Inc. P.O. Box 3016, Manhattan Beach, CA CIS:75076,2603 BIX:jeffjacobs
shebs@utah-orion.UUCP (07/11/86)
In article <1405@well.UUCP> jjacobs@well.UUCP (Jeffrey Jacobs) writes: > >In <137@utah-orion.UUCP>, Stan Sheb writes: > >>I have an implementation of 3-Lisp that used to work in PSL, but then >>I translated it to Common Lisp, and as of yet have not gotten the >>necessary readtable hacking to work yet > >So much for the wonderful portability of Common Lisp! I was afraid somebody might jump on this, and tried to phrase vaguely to leave some doubt, but obviously that didn't help. OK, I'll explain. 3-Lisp requires a special readtable that redefines things like #\(, #\`, #\$, etc. The 3-Lisp implementation code in CL also likes a couple of extra definitions, although they're not required. During the process of firing up a 3-Lisp, you need to flip back and forth between these two readtables several times. Fine, just create the two readtables and rebind them! Unfortunately, the two implementations I worked with were PCLS and an early version of a commercial Common Lisp. PCLS is embedded in PSL, which stores macro character definitions on property lists, and this is the behavior that PCLS inherits. This is OK since PCLS is a subset, but it means that rebinding of *readtable* is out. There is another way to go that involves the copy-readtable function, but PCLS didn't have that either, and the commercial CL's version didn't work. So I hacked out one for PCLS but it's unfinished, since I'm now working on a full reader instead of borrowing PSL's. To put all this in perspective - I spent about 3 hours converting the 1600 lines of the 3-Lisp implementation from PSL to CL, and about 2 hours fiddling with the readtable stuff in PCLS and the other CL. 3-Lisp is not real high on my list of priorities... >To add another story about the wonders of porting to Common >Lisp from a Local User's Group meeting of one of the Lisp Machine >companies, "I ported a large program from Zeta-Lisp to Common >Lisp. After I had it almost working, I decided I'd had enough. I >wouldn't use the Common Lisp version". People writing Zetalisp programs have a habit of using everything in the language they can find, and as a result find they can't port their program from Zetalisp to *any* other dialect. Blame Symbolics, not Common Lisp. >For those who have been unable to understand some of my points >about Common Lisp and how it SHOULD have been done, see the >EuLisp/ISO draft standards! Eulisp proposes some fairly radical things, some of which (like explicit environment objects) have not really been tested in a production environment. If you read Julian Padget et al's paper that will appear at the Lisp conference, you will find out about a great many holes that need plugging. Of Eulisp's three levels of functionality, the top is essentially Common Lisp, so a "full" Eulisp implementation will be indistinguishable from a Common Lisp. If CL is the worst thing that's happened to Lisp, Eulisp won't be any better... >-Jeffrey M. Jacobs, CONSART Systems Inc. stan shebs
rfb@h.cs.cmu.edu.UUCP (07/12/86)
>>I have an implementation of 3-Lisp that used to work in PSL, but then >>I translated it to Common Lisp, and as of yet have not gotten the >>necessary readtable hacking to work yet > >So much for the wonderful portability of Common Lisp! Of course, most people will realize that translating from one language to another has nothing at all to do with the portability of the target language. ---------------------------------------------------------------------- Rick Busdiecker The Robotics Institute ...!seismo!h.cs.cmu.edu!rfb (UUCP) Carnegie-Mellon University rfb@h.cs.cmu.edu (ARPA) Pittsburgh, PA 15213 (412) 268-7654 ----------------------------------------------------------------------
jjacobs@well.UUCP (07/12/86)
In my original msg, portability should have been COMPATABILITY. mea culpa -Jeff Jacobs, CONSART Systems Inc., Manhattan Beach, CA
martin@kuling.UUCP (07/16/86)
In article <1405@well.UUCP> jjacobs@well.UUCP (Jeffrey Jacobs) writes: > >In <137@utah-orion.UUCP>, Stan Sheb writes: > >>I have an implementation of 3-Lisp that used to work in PSL, but then >>I translated it to Common Lisp, and as of yet have not gotten the >>necessary readtable hacking to work yet > >So much for the wonderful portability of Common Lisp! Common Lisp is not supposed to compatible with all other existing lisps. CL is portable between different CL implementations. You have the same problems porting from lisp X to CL as from lisp X to any other lisp Y. > >To add another story about the wonders of porting to Common >Lisp from a Local User's Group meeting of one of the Lisp Machine >companies, "I ported a large program from Zeta-Lisp to Common >Lisp. After I had it almost working, I decided I'd had enough. I >wouldn't use the Common Lisp version". > >The person telling this story shall remain nameless, but definitely >knows what s/he is doing... > I have ported a large program from FranzLisp to Common Lisp. No problems at all. Got some bugs fixed in the original at the same time, so in the new version works better. And it runs easy on the Lambda (in CL-mode) so CL is indeed portable. >... > >-Jeffrey M. Jacobs, CONSART Systems Inc. >P.O. Box 3016, Manhattan Beach, CA >CIS:75076,2603 >BIX:jeffjacobs -- Per-Erik Martin, Computing Science Dep., Uppsala University, Sweden UUCP: martin@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!martin)
jjacobs@well.UUCP (07/18/86)
In <1405@well.UUCP>, Stan Shebs writes: >>For those who have been unable to understand some of my points >>about Common Lisp and how it SHOULD have been done, see the >>EuLisp/ISO draft standards! >>-Jeffrey M. Jacobs, CONSART Systems Inc. >Eulisp proposes some fairly radical things, some of which (like >explicit environment objects) have not really been tested in a >production environment. If you read Julian Padget et al's paper >that will appear at the Lisp conference, you will find out about >a great many holes that need plugging. Of Eulisp's three levels >of functionality, the top is essentially Common Lisp, so a "full" >Eulisp implementation will be indistinguishable from a Common Lisp. >If CL is the worst thing that's happened to Lisp, Eulisp won't be >any better... I have read Padget et alia's paper. Since it has not yet been officially published and we were requested not to quote it or discuss it before then, I will abide by the authors' wishes and defer discussion of the paper _itself_ until it's publication. I will simply state that the paper describes a MUCH better **approach** to philosophy and design than that of Common LISP. "a great many holes that need plugging" is grossly misleading. It implies that there are major inconsistencies and/or a lack of solutions to problems. This is simply not the case, in either Padget's paper or the proposed ISO/EuLisp standard. There are open questions, which is why the ISO/EuLisp is still a draft, but these are not "holes". In my draft of the ISO standard, dated June 1, I can find no reference to an "explicit environment object". Even if there is such a data type in versions which I have not seen, it is hardly a radical or untested idea; it goes back to the earliest days of LISP. When discussing the "top level" of EuLisp, level 2 there is an apparent desire to be _compatible_ with Common LISP, NOT to be a "full" CL. The standard point out in graphic detail many of the problems of CL, at one point using the word "pornographic" to describe the number of ways in which a symbol can be used. This is a very open issue, and, given the inconsistencies and problems in Common LISP, I strongly doubt that they would commit themselve to hanging themselves by a foolish committment to a standard still in need of major revision. Mr. Shebs seems to have a basic inability to distinguish between forests, trees and shrubs. He is either unwilling or unable to understand and address the issues. He defends Common LISP with a nearly religious zeal, using a style and technique that remind me most of a post-pubescent "student of Objectivism. His preferred means of 'rebuttal' consist foremost of ad-hominem, and"straw men" arguments. The balance consists mostly of stamping things as "bogus" or "a crock". Misstatement fills out his repertoire. Technical content is either totally lacking or impossible to find among the derogatory adjectives. In the same message, he goes on to explain why he couldn't port 3-LISP from PSL to PCLS. The basis of his excuse is that PCLS is "a subset". There are no accepted subsets of Common LISP, as Mr. Shebs himself has previously stated. So PCLS is simply incomplete and therefore "broken". Since Mr. Shebs takes a great deal of credit for PCLS, he has nobody but himself to blame for it's deficiencies. In my first article, I pointed out the difficulties and time required to do a "full" implementation of CL; PCLS is not only not full, it doesn't even cover some of the basics (if there are any in CL). Perhaps if he spent more than five hours at something, he would have something to show us. His claims of converting 1600 lines of code in 3 hours are totally meaningless if it doesn't work, particularly when he gives up on the rest after 2 hours! >but PCLS didn't have that either... I wonder what else is missing! Given all of the above, I find it difficult to take Mr. Shebs seriously. When he has something complete that works, learns about the basics of debate and argumentation, and learns a little basic politeness, I'll reconsider taking him seriously. Jeffrey M. Jacobs, CONSART Systems Inc. P.O. Box 3016, Manhattan Beach, CA 90266 CIS:75076,2603 BIX:jeffjacobs
shebs@utah-orion.UUCP (Stanley Shebs) (07/19/86)
(I wouldn't bother, but replying to flames is easier than working on a thesis...) In article <1450@well.UUCP> jjacobs@well.UUCP (Jeffrey Jacobs) writes: >I have read Padget et alia's paper. Since it has not yet been >officially published and we were requested not to quote it or discuss >it before then, I will abide by the authors' wishes and defer discussion >of the paper _itself_ until its publication. No such request came with my copy. >There are open questions, which >is why the ISO/EuLisp is still a draft, but these are not "holes". I consider an "open question" in a language design to be the same as an "open hole"; a "settled" or "closed" question is a "closed hole". >In my draft of the ISO standard, dated June 1, I can find no reference >to an "explicit environment object". Even if there is such a data >type in versions which I have not seen, it is hardly a radical or >untested idea; it goes back to the earliest days of LISP. It's not been standardized on, but both Eulispers and Common Lispers have been talking about it for awhile. The hard part is having environment objects that are more sophisticated than the simple alists that UCI Lisp allows in certain contexts. For instance, the "environment" in a compiled program includes the machine's stack, which almost certainly includes non-Lisp objects. If one were to make an ordinary data object out of this, it would be necessary to ensure that such things are insulated from the Lisp world. Also, an explicit environment object would be pretty useless unless you could install it directly, but I don't know of any Lisp that can take such a data structure and reinstall it into the machine's stack. I'd be glad to hear of any implementation that does this efficiently. >The standard point out in graphic detail many of the problems of >CL, at one point using the word "pornographic" to describe the number >of ways in which a symbol can be used. Well, after reading large piles of literature, I've come to the conclusion that Europeans are, on the whole, considerably better flamers than Americans. I can't think of any language design (even UCI Lisp) anywhere that I would stoop to describing as "pornographic", and especially not in print! >This is a very open issue [in the Eulisp draft], "open issue" == "open question" == "open hole". >Mr. Shebs seems to have a basic inability to distinguish between >forests, trees and shrubs. He is either unwilling or unable to >understand and address the issues. What issues are you referring to? If it's language design issues, I'm not particularly interested - arguing whether Eulisp or Common Lisp is "better" is akin to arguing whether Pascal syntax design is better than C syntax design. It's just too trivial. On the other hand, arguing about the effect of designs on implementations is valid, but it's very hard to know what the TRUE effects are (see below). >He defends Common LISP with a nearly religious zeal, [...] >Misstatement fills out his repertoire. Technical content >is either totally lacking or impossible to find among the derogatory >adjectives. I thought Usenet was not the place for ad hominem? Mr. Jacobs' insults aside, I must admit to finding myself in an uncomfortable position defending a large committee-designed language. Logically, I should defend Cobol, PL/I, A*a, and Algol-68 also. But there's a deeper issue, which is about the notion of "language design", and about which there is some confusion, judging by some recent postings. The misconception is about "right" and "wrong" designs. This is totally meaningless. A language design is just that - a design. Talking about "right" and "wrong" features is like saying the design of the Golden Gate bridge is "right" and that of the Verrazano Narrows Bridge is "wrong", or that Jackson Pollock paints "right" and Leonardo painted "wrong". Language design is fundamentally an emotional process, if done by one person, and fundamentally a political process, if done by a committee. There are really no technical or logical means for deciding on the names of functions, or how variables will be scoped, or how large the language will be. I am completely and perfectly free to design a language in which "+" operates normally on numbers, but for which (+ "jjacobs" "sshebs") returns "flame". NO ONE can tell me this is a wrong thing to do. It might be strange, or confusing, or disapproved of by the Knights of the Lambda Calculus, but you can't *prove* it to be incorrect. This is not to say that a design decision does not have consequences! On the contrary, painters and architects and language designers operate under a great many constraints - language designers maybe more so than the others, because a language design will have an enormous numbers of (opposing) consequences, in space vs time performance, length and complexity of source code, compatibility with other languages, and so forth. The study of these consequences is a fascinating but extremely complicated business, and has never been formalized (now we're getting into my thesis topic!). To use my example, extending the domain of "+" might (under certain circumstances) slow it down, or make the language manual longer, or complicate the possible representations for strings and numbers. (It will certainly annoy some people, but that's not a technical consequence.) In the process of doing my research, I have had the opportunity to look at all of this at leisure, and am now much more aware of the subtleties involved, and in particular many of the technical consequences of Common Lisp design decisions. Some of them are surprising, others merely obscure. Things that superficially appear to be "bad" (for instance function protocol) have a great many pleasant consequences, while other things that are superficially "good" (for instance the traditional Lisp macroexpansion) have some unpleasant consequences. In general, feature X of language Y will have both good and bad consequences, and the language designer must weigh these against each other (once again, a non-technical process). It is not inconsistent for me to say "the reason for feature X of language Y is that Z; however, W" and at the same time to say "I really hate feature X". Now for an application: many people claim that Common Lisp's division of functions and values is "wrong", but many other people consider it to be "right". Of course, neither is the case. Merging of functions and values simplifies some programs, but it can lead to name conflicts, which is a traditional bane of Lisp. The issue of *efficiency* of separate function cells is extraordinarily complicated; literature search shows dozens, maybe even hundreds of algorithms to take into account. Someone (not me!) could write an interesting dissertation that formally analyzes these methods. I mentioned politics as being the chief activity of design by committee. Eulisp has the luxury of relatively little political pressure being exerted on it from outside. That has some advantages for language design, but I wonder if it means that nobody really cares, and that Eulisp will be ignored by everyone outside of a small European community. The same interests in the USA that influenced the Common Lisp designers probably will not rewrite all of their software to suit Eulisp, so unless something dramatic happens, we're heading for a situation analogous to Fortran vs Algol in the 60s. It's sad, but politics doesn't interest me much anyway. Finally, just for the record, Common Lisp is not my favorite language. Those laurels are shared between the logic programming language MRS developed by Mike Genesereth and hist students at Stanford, and the equational language OBJ2 developed by Goguen, Meseguer, and others at SRI. I believe that the future of computer languages lies in the direction of those which subsume several programming paradigms (functional, logical, and object-oriented at least) in a common computational framework. In addition, the distinction between knowledge representation and algorithm encoding will be extremely fine. Lisp won't fade away - it will end up like Fortran, with a base of users dedicated to a stable language, but little interest from the research community. >There are no accepted subsets of Common >LISP, as Mr. Shebs himself has previously stated. Since I've been involved in studying and proposing plausible subsets of Common Lisp for nearly two years, I doubt that I would oppose the idea of subsets of Common Lisp! What *is* the case is that most subset proposals get shot down because they inevitably exclude someone's favorite feature, and then that someone decides that the full language is preferable to the subset, and withdraws real support from the subset. Politics... >Since Mr. Shebs takes a great deal >of credit for PCLS, he has nobody but himself to blame for it's [sic] >deficiencies. That's true. Understand, however, that PCLS must operate under a large number of constraints. The goals of PCLS were: 1) to embed a Common Lisp subset in PSL, 2) to avoid making massive changes to PSL, 3) to not compromise the efficiency of PCLS relative to PSL, 4) to investigate the methods and problems of Common Lisp implementation, and 5) to make PCLS available to PSL users to ease the transition from PSL to Common Lisp. Goals 1, 2, and 5 together mean that we must retain complete compatibility with PSL, sufficient that existing PSL programs will run in PCLS if one stays in the "psl" package. Another desirable consequence is that PCLS comes up on the dozen different PSL systems fairly easily. To satisfy goals 2 and 3, we had to implement all compiler optimizations as source-to-source transformations - we couldn't touch the PSL compiler. Fortunately, we were able to come up with some transformations that optimize most PCLS programs to the performance of their PSL equivalents. Goal 4 has been satisfied by experimenting with and analyzing assorted strategies. Many modules of PCLS have been re-implemented several times, each time better than the last, and some of the code is quite elegant, compared to other implementations I've studied. All of the stated goals have been satisfied so far. Note that "implementing a full Common Lisp" is not and never has been one of the goals for PCLS. PSL and CL are sufficiently different than embedding one in the other will never truly win. We are starting to discuss the design of a full Common Lisp that will incorporate what we've learned, and that will be a publicly available "showpiece" implementation using the best compiler and runtime system techniques - it will however be a year or two before this is done. >Perhaps if he spent more than five hours at something, he would >have something to show us. His claims of converting 1600 lines >of code in 3 hours are totally meaningless if it doesn't work, particularly >when he gives up on the rest after 2 hours! Well, I spent another hour at it (in HP CL) and finally discovered that although I had introduced a function to encapsulate the readtable changes, it was never being called! Even the best programming languages can't do much about amnesia.... Once that was taken care of, 3-Lisp worked perfectly. When I finish writing up the documentation (and maybe doing just "a little more polishing" :-)), it will be available to anyone who wants it. >I wonder what else is missing! There's lots missing from PCLS, and I occasionally get requests to add "feature X". When I point out that the feature would require hacking or replacing large parts of PSL, they usually decide that it's not worth the effort (and then harass me about working harder on the new implementation, which alas is also not part of my thesis work). >Given all of the above, I find it difficult to take Mr. Shebs seriously. >When he has something complete that works, learns about >the basics of debate and argumentation, and learns a little basic >politeness, I'll reconsider taking him seriously. If you really don't take me seriously, then don't bother to insult me and my postings! Surely you're not being forced to type "F" instead of "N" to rn... >Jeffrey M. Jacobs, CONSART Systems Inc. stan the tired
ram@spice.cs.cmu.edu (Rob MacLachlan) (07/25/86)
The current discussion of Common Lisp and Eulisp seems to be missing the most fundamental aspects of the disagreement due to an obsession with superficial technical issues. The missing dimensions are the political and the psychological. It is evident from Mr. Jacobs messages that the Eulisp design effort has its true basis in anal retentive neurosis. Consider the frequent use of sexual metaphor and innuendo in his messages: >From: jjacobs@well >Subject: Re: 3-Lisp >Date: Fri, 18-Jul-86 12:12:50 EDT >Reply-To: jjacobs@well.UUCP (Jeffrey Jacobs) >Keywords: Lisp, 3-Lisp, purity, reflection > Consider the keyword "purity" in his subject header. He has barely begun his ejacluations, yet he has already revealed his latent pederasty for the world to see. >For those who have been unable to understand some of my points >about Common Lisp and how it SHOULD have been done, see the >EuLisp/ISO draft standards! > [In another message, referring to Mr Shebs.] >He is either unwilling or unable to understand and address the issues. > As is usually the case with borderline psychotics, he assumes that anyone who disagreees with him has misunderstood him. Unfortunately for him, we understand him all too well. >I have read Padget et alia's paper. Since it has not yet been >officially published and we were requested not to quote it or discuss >it before then, I will abide by the authors' wishes and defer discussion >of the paper _itself_ until it's publication. > This obsession with secrecy would normally be considered an indication of paranoia, but in this case I believe that is caused by a fear of inadequacy (here quite justified). > I will simply state that >the paper describes a MUCH better **approach** to philosophy > He loses touch with reality, forgetting that we are discussing a practical programming language rather than some misguided attempt to make a philosophically pure language. >"a great many holes that need plugging" is grossly misleading. It >implies that there are major inconsistencies and/or a lack of solutions >to problems. This is simply not the case, in either Padget's paper or >the proposed ISO/EuLisp standard. There are open questions, which >is why the ISO/EuLisp is still a draft, but these are not "holes". > See how he is made uncomfortable by the phrase "plugging holes." His fears of sexual inadequacy lead him to attempt to redefine the terms by equivocating. >The standard points out in graphic detail many of the problems of >CL, at one point using the word "pornographic" to describe the number >of ways in which a symbol can be used. > Thus we see that a subconscious sexual prudery underlies the entire language design; Mr. Jacobs is not the only unstable person involved. The themes of "purity" and "cleanliness" provide strong confirmation. A major subconscious theme of the anal retentive personality is acute uneasiness with bodily secretions, either literal or symbolic. Cleanliess thus becomes an obsession in their diseased minds. >Mr. Shebs seems to have a basic inability to distinguish between >forests, trees and shrubs. > Recall that "beating around the bush" is a euphimism for adultry. >He defends Common LISP with a nearly religious zeal, using >a style and technique that remind me most of a post-pubescent >"student of Objectivism." > Yes, but the ambience of Eulisp is decidely pre-pubescent. Not only do the designers lack the experience of the Common Lisp designers, they are physically incapable of this experience due to their comittment to obsolete hardware. The problem is that in Lisp design (as in other things), theoretical knowledge is no substitute for experience. Their attempt to construct a standard out of youthful enthusiasm and thin air is doomed to failure. The so-called "Eulisp standard" is merely a case of premature ejaculation. I freely admit the shortcomings of the current Common Lisp definintion, but it is pure wishful thinking to suppose that a full specification for a language having the power of Common Lisp can be constructed in only a year or two. >His preferred means of 'rebuttal' >consist foremost of ad-hominem, and"straw men" arguments. > May I point out that you are the innovator in the character asassination department. The second half of the rather long message to which I am replying is entirely devoted to attacking Mr Shebs. On occasion, he did lower himself near you level, but on the whole has been an exemplar of reasonableness compared to you. If a Common Lisp implementor made an attack on your person, you would notice it, as it would resemble this message. >Given all of the above, I find it difficult to take Mr. Shebs seriously. >When he has something complete that works, learns about >the basics of debate and argumentation, and learns a little basic >politeness, I'll reconsider taking him seriously. > Rest assured that no serious language designer will take you seriously. Of course if you had any constructive criticism to offer, you would be welcome to join Mr. Shebs in the Common Lisp community. >Jeffrey M. Jacobs, CONSART Systems Inc. >P.O. Box 3016, Manhattan Beach, CA 90266 >CIS:75076,2603 >BIX:jeffjacobs > Rob MacLachlan, Carnegie Mellon University. Programmer, Spice Lisp project: "Making the free world safe for symbolic programming..."
jjacobs@well.UUCP (Jeffrey Jacobs) (07/26/86)
ll.UUCP> <1041@spice.cs.cmu.edu> Sender: Reply-To: jjacobs@well.UUCP (Jeffrey Jacobs) Followup-To: Distribution: Organization: Whole Earth Lectronic Link, Sausalito CA Keywords: Lisp, 3-Lisp, purity, reflection As this discussion takes another turn toward the bizarre, Rob MacLachlan states in <1041@spice.cs.cmu.edu> >>From: jjacobs@well >>Subject: Re: 3-Lisp >>Date: Fri, 18-Jul-86 12:12:50 EDT >>Reply-To: jjacobs@well.UUCP (Jeffrey Jacobs) >>Keywords: Lisp, 3-Lisp, purity, reflection >> >Consider the keyword "purity" in his subject header. He has barely begun >his ejacluations, yet he has already revealed his latent pederasty for the >world to see. This is pretty funny, but "purity" originated with Mr. Shebs, NOT ME!!! A note on what an "ad-hominem" argument consists of: an ad-hominem argument is a logical fallacy in which the [character, intelligence, sexual preferences, etc] of the speaker are attacked rather than the content of the argument. Examples are "The speaker is an ignorant know-nothing, so his arguments are worthless". "The speaker is a communist, so his arguments are worthless". "The speaker is a homo-sexual, so his arguments are worthless". I really expect better of you people... Jeffrey M. Jacobs, CONSART Systems Inc. P.O. Box 3016, Manhattan Beach, CA 90266 CIS:75076,2603 BIX:jeffjacobs USENET: well!jjacobs "Making symbolic programming AFFORDABLE in the free world..."
oz@yetti.UUCP (Ozan Yigit) (07/29/86)
Keywords: Lisp, 3-Lisp, purity, reflection Summary: In article <1041@spice.cs.cmu.edu> ram@spice.cs.cmu.edu (Rob MacLachlan) writes: > >As is usually the case with borderline psychotics, he assumes that anyone >who disagreees with him has misunderstood him. Unfortunately for him, we >understand him all too well. > DO you ?? If you get your nose off that highschool psych text, maybe you can *really* understand. > >He loses touch with reality, forgetting that we are discussing a practical >programming language rather than some misguided attempt to make a >philosophically pure language. > Practical programming language ?? What would a psych minor know about that ?? >...Cleanliess thus becomes >an obsession in their diseased minds. > Diseased minds ?? No psychologist worth his/her salt would use the term so losely. Perhaps you should check your highschool text once again... > >Rest assured that no serious language designer will take you seriously. > Speculation. I speculate that he will be taken more seriously than you. > >Programmer, Spice Lisp project: > Gasp !!!!!!!! oz -- The best way to have a Usenet: [decvax|ihnp4]!utzoo!yetti!oz good idea is to have a Bitnet: oz@[yusol|yuyetti].BITNET lot of ideas. Phonet: [416] 736-5053 x 3976
harrison@uicsrd.CSRD.UIUC.EDU (07/31/86)
To those who are using this notesfile as a vehicle for childish insults: You are driving away those of us who haven't an indefinite amount of time for reading such nonsense; please stop it.