On 17 Mar 2002 02:15:21 -0800, Thomas Bushnell, BSG wrote:
> #t and #f are constants, and that's why Scheme makes them not just > symbols. The issue is that symbols are *all* available for variable > names. There is no more reason to have t use up a variable name than > 6.
Oh, so you can use 6 as a variable name in Scheme, then, can you?
-- Malum est consilium quod mutari non potest -- Publilius Syrus
To even be able to argue reasonably coherently about the differences, one must understand both Scheme and CL at a very deep level at the very least - which I don't. (I would note that lots of the comments in this traditional Scheme/CL flamethread seem to show a large degree of misunderstanding or just trolling from both sides...).
I'd say that only members of some sort of "Lisp" community would be able to do the argung in the first place.
I would say that the name "Lisp" denotes languages like Scheme and CL, among others. Show a non-Lisper with some computing experience either Scheme or CL, and they'll identify either as Lisp. Your identifier in human society is what other people call you, not the name you choose for yourself.
From the "outside", Scheme and CL are Lisps, and the arguments between Scheme and CL people are similar to the arguments between Roman Catholics and Protestants - they're both just more vampire-cultist christians to the outside observer, though a member of either group will argue at length about con/trans-substantiation, the status of the virgin mary, etc....
So, probably only a devoted member of the community is going to be able to understand the issues involved, and thus I would lump both Scheme and CL together as implementations of different "aspects" of an underlying archetypal Lisp that the Lisp community recognises at a subconcious level, by the fact that people on this group are even arguing about Sheme and CL in the first place.
Saying "Our Lisp is the One True Lisp, and what you're calling Lisp is Not Lisp" is _just_ like the stupid schisms you see in religions.
Much better to say Scheme and CL are aspects of the One,,,
* Thomas Bushnell, BSG | Implementing it *efficiently*. I don't think you understand what the | issues are with hygienic macros; maybe you should go read the papers.
Perhaps you should explain it better? You, too, seem to demand that other people pay for your lacking education, but when it gets time to reverse this principle, you seem to get just as exasperated as those you do not listen to. At least this shows _me_ something, if not you.
/// -- 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.
* Thomas Bushnell wrote: > Implementing it *efficiently*. I don't think you understand what the > issues are with hygienic macros; maybe you should go read the papers.
Can you be clear what you mean about `efficiently'. For instance if I blindly rename *all* symbols I bind then probably for a typical macro this is 0-10 symbols, and the overhead is entirely at macro expansion time. There must be some other meaning of `efficient' here.
* Paul Foley wrote: > So put it in a different package. You *can* even do things like > (eval-when (:compile-toplevel :execute) > (shadow 'cl:t)) > (defun foo (t) > (+ t 50)) > (eval-when (:compile-toplevel :execute) > (shadowing-import 'cl:t))
Would not this work (in a package where T is not CL:T)
(define-symbol-macro t cl:t)
do the trick?
Now you can bind T painlessly, but free references mean CL:T and the compiler can do any constant folding &c.
> To even be able to argue reasonably coherently about the differences, one > must understand both Scheme and CL at a very deep level at the very least -
Not at all. Lisp1 vs. Lisp2 seems simple enough. Pattern transformation macros vs. computational macros (er..is there a better standard name?). Primarily functional vs. multi-paradigm. Etc.
Of course, for the latter, it helps to understand what a functional language vs. a muti-pardigm (or perhaps, strongly OO) language is, but that should be more or less general knowledge. If you don't understand *that* then, ok, you probably can't make that distinction between scheme and lisp, but then maybe you shouldn't make judgements about their differences at all.
[snip]
> I'd say that only members of some sort of "Lisp" community would > be able to do the argung in the first place.
If this is supposed to be because you have to have used Lisps extensive, yadda yadda, then I don't think that's true. Or, at least, not in any strongly interesting sense.
> I would say that the name "Lisp" denotes languages like > Scheme and CL, among others.
It's really weird how you set up the Lisp Community as the only place where such analysis is *possible*, cast yourself out of the Lisp Community, *then make a pronoucement* that ordinarily is based on the sort of analysis which you just said you can't do (correctly).
> Show a non-Lisper with some computing > experience either Scheme or CL, and they'll identify either as Lisp.
Presumably either on superficial grounds ("parens with prefix operators"), possible mistaken advertizing ("well, we did both in our lisp section class"), a very certain perspective ("well, compared to C, they're lisps, as is Perl"), or on real grounds because they followed some debates and came down on the scheme is a lisp side.
Only the last is remotely interesting intellectual, though the others might be interesting from a marketing perspective.
> Your > identifier in human society is what other people call you, not the name > you choose for yourself.
And now we have the justifying principle which is to make it all work: And it is a repugnant one. Even if convention and some sort of community consensus is necessary for "correct" labeling, why must it be the community of the studiously ignorant?
I had a student ask about my name, and I told him it was Iranian, and he asked if my family had been Muslim, and I said, "No, Zorostrian". "Ah", he said, "they were Parsis". I said, no, the Parsis are the decendents of those Zorostrians that fled to India. He told be it didn't matter, I was a Parsi.
Well, look, "bob", not only was he wrong, but he was a jerk.
> From the "outside", Scheme and CL are Lisps,
Not necessarily. If you look at the various grounds I listed for the "outsider's" perspective, you'll see that some are JUST FREAKING WRONG. E.g., KIF is not a Lisp. Prolog with Sexprs syntax isn't a Lisp. Yet both may be classified as a lisp by the person with a parens fixation.
> and the arguments between > Scheme and CL people are similar to the arguments between Roman Catholics > and Protestants - they're both just more vampire-cultist christians to the > outside observer, though a member of either group will argue at length > about con/trans-substantiation, the status of the virgin mary, etc....
This is *really* offensive.
Interesting that you conflate all Protestants.
Really interesting that the outsiders have *all* the defining power. Sorry, that's not how it usually goes. Oh, and yes, my ancesters are *Iranian*, not *Persian*. Thanks ;)
I guess the notions of respect and tolerance and understanding are just completely foreign.
[snip]
I guess this must of been a joke. If so, it didn't come off very well.
> > and the arguments between > > Scheme and CL people are similar to the arguments between Roman Catholics > > and Protestants - they're both just more vampire-cultist christians to the > > outside observer, though a member of either group will argue at length > > about con/trans-substantiation, the status of the virgin mary, etc....
> This is *really* offensive.
That lies in the eye of the beholder. :) I do _not_ feel offended. Even though I live in a mainly protestant area, but nobody does care here either.
> So you say. Kent Pitman says that CL does *not* have hygenic macros, > but that it's not a problem in CL.
An MIT guy and a Harvard guy went into a bathroom together and went up to the urinal to pee. After finishing, the MIT guy went to leave the room without washing his hands. The Harvard guy, appalled, called after him: "At Haahhhhvaahhhd, they teach us to wash our hands after we urinate." The MIT guy looked back at him and said, "At MIT they teach us not to urinate on our hands."
Moral? The goal of hygiene is effect, not process.
... with apologies, btw, to Harvard folks. No slight intended. I'm sure you've got your own MIT/Harvard jokes where you've exchanged heroes and villains from the original and correct form of the joke and where it still kinda almost sounds funny, at least to you guys...
> Would not this work (in a package where T is not CL:T)
> (define-symbol-macro t cl:t)
> do the trick?
> Now you can bind T painlessly, but free references mean CL:T and the > compiler can do any constant folding &c.
Yes, I was going to suggest this. That's the reason I talked the (X3)J13 committee into accepting DEFINE-SYMBOL-MACRO in the language in the first place--it allows the implementation of compatibility with Scheme in a straightforward way, both for this and for lexical globals.
Doing this would probably satisfy a Schemer. I don't think it would satisfy a CL person because (eq (not nil) 't) won't work. But the choice is really just what universe you want to live in. There are many tools for creating different world-models in CL...
> The really significant difference is not the hygene one, which CL > could have without too much trouble. The big difference is that CL > thinks of macros as *functions* from forms to forms, and Scheme has a > simpler pattern transformation method.
I had to laugh here because the Scheme community would never tolerate me saying a statement like "The real issue between the scheme sort function and the CL sort function is that Scheme thinks everything is just handled by a single general function and CL pattern-matches on a few simple keywords for finer grained functional control." I would be laughed out of the room for calling a less general mechanism "simpler".
Not that I don't agree that pattern or keyword things are simpler.
I just don't agree that you shouldn't have access to the fully general system (which, btw, CL SORT doesn't keep you from doing, it just _also_ lets you manage things by keywords, and which, btw, Scheme macros don't let you do because it _only_ lets you manage things by pattern matching).
> Kent M Pitman wrote: > > This is a nice succinct example of where we take a different view on > > the same data. I perceive that you think writing #'foo is somehow a > > negativity because you don't what to write it. I think what you don't > > see is that I don't have any negative take on the writing of #'foo and > > so I am not negatively biased away from using it.
> Yes. What I said was misleading here. It's not that having to write > #'foo instead of foo is a burden, it's that the explicit coercion from > function to value, if you will, induces a subtle psychological set that > functions are not values, or at least not like other values.
That sounds confused. (function foo) doesn't "coerce" a "function" to a "value". It looks up the value that the symbol foo is bound to in the currently active "function" environment.
Now how muddied must a programmer's mind be, to believe that there is a fundamental difference between values based on the environment that they came from? Do Scheme programmers regularly feel that values obtained from the global lexical environment are fundamentally different from values obtained from some other environment? I don't think so.
I'm fairly certain that CL programmers don't see a fundamental difference between values looked up in different symbol namespaces (aka packages), and neither would a CL programmer see a fundamental difference between the value he gets from (function foo), to the one he gets from foo, or (symbol-function 'foo) or (gethash 'foo ...), or any other form. They are all values, though some of them might be of type function and some of another type.
It rather seems to me that your own slightly confused understanding of Common Lisp is the reason for the bias perceived by you, and nothing that CL programmers encounter or entertain.
Regs, Pierre.
-- Pierre R. Mai <p...@acm.org> http://www.pmsf.de/pmai/ The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. -- Nathaniel Borenstein
> > > and the arguments between > > > Scheme and CL people are similar to the arguments between Roman Catholics > > > and Protestants - they're both just more vampire-cultist christians to the > > > outside observer, though a member of either group will argue at length > > > about con/trans-substantiation, the status of the virgin mary, etc....
> > This is *really* offensive.
To me.
> That lies in the eye of the beholder. :) I do _not_ feel > offended. Even though I live in a mainly protestant area, but nobody > does care here either.
Actually, it's not the Prot/catholic/christian bash that offended me :) Well, much.
I dislike the appropriation of "outside observer". As niether Christian (or religious), nor Schemer, nor CLer (more than dabbler), I *really* resent the idea that the "outside observer" is supposed to be such a stupid jerk as is painted above. Outsider ~= ignorance and not caring about that ignorance.
> > Implementing it *efficiently*. I don't think you understand what the > > issues are with hygienic macros; maybe you should go read the papers.
> Can you be clear what you mean about `efficiently'. For instance if I > blindly rename *all* symbols I bind then probably for a typical macro > this is 0-10 symbols, and the overhead is entirely at macro expansion > time. There must be some other meaning of `efficient' here.
I think that what he means is `automatically' or `transparently'. If a `hygienic macro' is one that avoids all name conflicts, then you can get them by judicious use of GENSYM. What Scheme's pattern matching macros give you is automatic deduction of what needs to be GENSYM'ed.
This can in fact be done in Common Lisp by `painting' the code that is being substituted, but while this may be `the right thing' for Scheme, it is `solving a non-problem' in Common Lisp.
Erik Naggum wrote: > 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).
It probably surprises you that I was one of the people who pointed out the need for this restriction when Common Lisp was being standardized.
> It's right that Lisp2 doesn't force you to follow those rules, but if > you don't follow them, then you can't claim that CL macros are > hygenic.
On 15 March, at 11:10:19 PST, Rahul Jain quoted the above and replied:
> No one claimed that they are. Your reading skills are deteriorating.
On 15 March, at 23:50:16 PST, Rahul Jain wrote:
> Common Lisp has hygenic macros, too.
For the record: Common Lisp does not have hygienic macros.
Hygienic macros are not just macros that avoid inadvertent name captures provided all programmers involved follow a certain programming discipline and don't make any mistakes, as everyone agrees is true of CL macros; hygienic macros are macros that avoid name captures no matter how incompetent the programmers and no matter how many mistakes they make.
"Hygienic macros" were invented circa 1986 by Eugene Kohlbecker, and have been the subject of quite a few research papers since then; see http://library.readscheme.org/ and click on "Macros".
It would not be hard to add hygienic macros to Common Lisp, although the fact that CL is a Lisp2 does create a certain technical problem that do not arise in a Lisp1. I would be happy to discuss this with anyone who has first understood the concept of hygienic macros and the standard algorithms for implementing them.
Kent M Pitman wrote: > I sometimes see my role in the possibly-moribund Scheme authors > committee as the well-meaning but ineffectual mirror of yours in the > CL community, so we are kindred spirits you and I, each doomed to have > all the power of a nagging conscience in the face of actions beyond > our control....
Quite so.
> If I would start seeing words of support from the Scheme community, and > active encouragement from such influential people that they should embrace > and respect CL, I would take a different posture.
I cannot in good conscience encourage everyone to embrace CL, just as I cannot in good conscience encourage everyone to embrace Scheme or Java. They're just programming languages, and people should use a language when it's a good tool for the job at hand, and avoid a language when it's the wrong tool.
I do encourage people to respect Common Lisp, just as they should respect Scheme or C++ or Java. That is to say, all programming languages deserve critical respect: Acknowledge what they do right, but don't turn a blind eye to their shortcomings, and don't pretend they are anything more than what they are.
Programming languages don't have feelings, so their feelings aren't hurt when they are criticized. The people who form a language community have feelings, though, and those feelings are easily hurt when their favorite language is criticized. If we were all more careful not to identify ourselves with our favorite language(s), and to view our favorite language(s) more critically, our feelings wouldn't be so easily hurt.
> So when people criticize CL, Scheme is criticized in return. And > that's a shame.
Not to mention a waste of time.
> Do you think it would be useful or productive at this point to try to > create a Lisp1 preprocessor for CL?
No. Maybe I'm wrong, but I think it's too late in the game. CL and Scheme have by now found their own niches and user communities, with remarkably little overlap.
That wasn't the ideal outcome, but it wasn't the worst possible outcome either.
It's been nice talking to you, Kent. I think we've made some progress toward understanding each other's point of view.
Paul Foley <mycr...@actrix.gen.nz> writes: > On 17 Mar 2002 02:15:21 -0800, Thomas Bushnell, BSG wrote:
> > #t and #f are constants, and that's why Scheme makes them not just > > symbols. The issue is that symbols are *all* available for variable > > names. There is no more reason to have t use up a variable name than > > 6.
> Oh, so you can use 6 as a variable name in Scheme, then, can you?
Actually, it troubles me enormously that Scheme has special cases from its usual rule about special forms and functions. I always felt like it would be "cleaner" if the car of the form were always a special form. So one would write
(LAMBDA (FOO) (CALL (VAR +) (VAR FOO) (QUOTE 3)))
I'm amused to see the otherwise pristine Scheme world take
(LAMBDA (FOO) (+ FOO 3))
as a "clean and regular" notation since it involves special cases that need not be in the language definition. Then again, they are special cases that suit the people who designed Scheme, so they are more blessed than the special cases other languages have, which don't suit the people who designed Scheme. This is an important distinction. ;)
If the Scheme language were more regular, the Lisp1/Lisp2 issue would be a lot less prominent. A lot of the aggravation is caused by selling the leftover real estate after the special operator namespace was grabbed. If CL had made a decision to say it was ok to use other &names for variables, the Scheme people would be all over us for the "irregular special case of" (defun foo (&x &optional &y) (+ &x (or &y 3))) which would be a perfectly valid program. Both Lisp1 and Lisp2 designers realized it was too lucrative a space to just leave empty after the allocation of special operators. CL made the arbitrary but consistent decision to allow "function names" and "macro names" in the car of a form when special forms were not there. Scheme made the arbitrary decision but consistent decision to allow arbitrary expressions in the car of a form when there was no special form. But then, weirdly, Scheme went back and haired up the rule with even more strangeness because now the rule is "Maybe it's a special form?", No? "Maybe it's a macro?", No? "Ok, now claim it's consistent to put a form here". But it's really not like that at all. Because LET is not a variable and I can't use LET anywhere but the head of a list to get its magic meaning. So the Scheme rule is quite inconsistent. CL, by contrast, pretty consistently says "look, it's an operator or nothing" and then it triages by operator type. That's in my book more consistent than the Scheme rule. And it bugs me to take grief for it as if we're the inelegant language. I'm happy to say there's some inelegance on both sides for wanting to grab the shorthand notation of (f x) at all where f is not a primop; but if we're not going to stop there and we're going to delve deeper, I think Scheme has its own share of dirty laundry to answer for.
> Actually, it troubles me enormously that Scheme has special cases from its > usual rule about special forms and functions. I always felt like it would > be "cleaner" if the car of the form were always a special form. So one would > write
There's just not an easy shorthand for variables that are not symbols...
And you have to define what predicate is used. I usually prefer EQUAL so I can contemplate notations like:
(LAMBDA ((FUNCTION F) F) (CALL #'F F))
Heh.
These are all just "possible worlds not visited" in Lisp design space. They are vaguely related to the world I talked about recently when I mentioned a bridge between the CL and Scheme worlds. There is a lot more detail one has to do, and I had worked out some of that...
In an attempt to throw the authorities off his trail, Bijan Parsia <bpar...@email.unc.edu> transmitted:
>> and the arguments between Scheme and CL people are similar to the >> arguments between Roman Catholics and Protestants - they're both >> just more vampire-cultist christians to the outside observer, >> though a member of either group will argue at length about >> con/trans-substantiation, the status of the virgin mary, etc.... > This is *really* offensive. > Interesting that you conflate all Protestants.
Protestants _do_ tend to have a fair bit of common ground, in having stemmed from common religious roots, in much the same way that pretty much all Scheme implementors and users would be reasonably expected to have common respect for R*RS, having Rather A Lot of Parentheses in their language, liking the notion of having first class functions around, and such.
> Really interesting that the outsiders have *all* the defining > power. Sorry, that's not how it usually goes. Oh, and yes, my > ancesters are *Iranian*, not *Persian*. Thanks ;)
I'm quite sure that the distinction isn't of too much import to me, not only from a strict utilitarian perspective, but also since both those names of peoples are _English_, and thus are highly likely to be of much more recent provenance than whatever were the names that Iranian or Persian ancestors actually used.
Personally, I figure that "Iranian" more than likely traces back to some word in Farsi, and that "Persian" likely also traces back to some (perhaps distinct) word in Farsi, and that any differences that result are likely to be most meaningful in Farsi (or whichever other language, almost certainly _predating English_, is most relevant).
Getting too excited about the English words strikes me as being as silly as getting deeply into bizarre interpretations of the Bible based on the niceties of English words, when reality is that the Bible was certainly _not_ written in the English language.
It's sorta like trying to draw sweeping conclusions about the CL standard based on looking at snippets of assembly language generated by CMU/CL. There may be legitimate conclusions to be found, but it would be far more worthwhile to actually read the HyperSpec...
> I guess the notions of respect and tolerance and understanding are > just completely foreign.
They're pretty "foreign" notions; with the number of "wars of intolerance" that have circled the globe, over the millenia, it is not at all clear to me that there is anywhere that they could be considered to be "domestic" notions... -- (concatenate 'string "cbbrowne" "@ntlug.org") http://www3.sympatico.ca/cbbrowne/finances.html Why do we put suits in a garment bag, and put garments in a suitcase?
> I just don't agree that you shouldn't have access to the fully general > system (which, btw, CL SORT doesn't keep you from doing, it just _also_ > lets you manage things by keywords, and which, btw, Scheme macros don't > let you do because it _only_ lets you manage things by pattern matching).
Most Scheme systems of course do provide access "under the hood" to the lower level non-hygenic system (though, with the general acceptance of R5RS macros, this is becoming *less* common for some curious reason).
The real problem is that providing transformation functions, rather than just pattern matches, makes it gobs harder to figure out just how hygiene is supposed to work. Do you have any ideas on what might do the trick?
> > How else will you get values in scheme, since symbols don't have > > values? Where else will the value of "t" as used in my macro come > > from? This is one reason why scheme _needed_ to have #t and #f, > > whether or not it was explicit at the time. Unfortunately, a user > > cannot implement such a feature.
> "Symbols don't have values"? They don't in CL either, except for > special variables, for which you might want to say that.
I'm not (only) talking about specials, but functions and constants, too. basically anything provided by the language standard.
> #t and #f are constants, and that's why Scheme makes them not just > symbols. The issue is that symbols are *all* available for variable > names. There is no more reason to have t use up a variable name than > 6.
Right, and when my application wants to define a constant, how does it do so?
> > > Except, that is, for the one case of "t" and "nil". Those values > > > *are* locked in at read time, by making those two symbols Very > > > Special. > > Wrong. The values of T and NIL are locked into the SYMBOLS. Nothing > > says that the string "t" has a true value. > And nothing I said was about the string "t"; it was about the > *symbols*, which are Very Special.
Exactly, the symbols. This is where scheme differs. None of the semantics of code can be determined from the symbols. Symbols are dependent creatures which only have meaning in a specific lexical environment. Otherwise, you'll be likely to use the wrong meaning.
> > In reality, this whole difference is just a side-effect of the issue > > of symbolic processing. > Your new mantra of the day! If you knew what it meant... oh, no, > you're just chanting. Ok.
I get the impression that THIS is your new mantra. Denying that I know what I'm talking about can be a very effective way of allowing yourself to keep believing what you think to be true.
-- -> -/ - Rahul Jain - \- <- -> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <- -> -/ "Structure is nothing if it is all you got. Skeletons spook \- <- -> -\ people if [they] try to walk around on their own. I really /- <- -> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <- |--|--------|--------------|----|-------------|------|---------|-----|-| (c)1996-2002, All rights reserved. Disclaimer available upon request.
"Joe Marshall" <prunesqual...@attbi.com> writes: > "Tim Bradshaw" <t...@cley.com> wrote in message > news:ey3bsdne1u0.fsf@cley.com... > > * Thomas Bushnell wrote:
> > > Implementing it *efficiently*. I don't think you understand what the > > > issues are with hygienic macros; maybe you should go read the papers.
> > Can you be clear what you mean about `efficiently'. For instance if I > > blindly rename *all* symbols I bind then probably for a typical macro > > this is 0-10 symbols, and the overhead is entirely at macro expansion > > time. There must be some other meaning of `efficient' here.
> I think that what he means is `automatically' or `transparently'. > If a `hygienic macro' is one that avoids all name conflicts, then you > can get them by judicious use of GENSYM. What Scheme's pattern matching > macros give you is automatic deduction of what needs to be GENSYM'ed.
> This can in fact be done in Common Lisp by `painting' the code that > is being substituted, but while this may be `the right thing' for Scheme, > it is `solving a non-problem' in Common Lisp.
Please, notice that there are *two* different kinds of inadvertant name capture that Scheme macros avoid. Only one of them can be worked around using gensym at macro expansion time.
(I do understand that common lispers feel that the other kind does not occur very often or at all in their code. No need to point this out.)
Matthias Blume <bl...@hanabi.research.bell-labs.com> writes: > Please, notice that there are *two* different kinds of inadvertant > name capture that Scheme macros avoid. Only one of them can be > worked around using gensym at macro expansion time.
I'm not sure I understand what you mean here. Do you want to say the two issues so we're all on the same page.
