Having read Touretzky's introduction and the first half of PG's On Lisp, I'm wondering what the advantages of a Lisp-2 are over a Lisp-1.
It seems to me that a Lisp-2's ability to use a single symbol to represent both a function and a value is a minor advantage, although I'm sure some regard it as a disadvantage. On the other hand, a Lisp-2 requires the clunky, IMHO, #' operator and cannot have a elegant, universal DEFINE like Scheme's.
Yet I've heard that a Lisp-1's macros are necessarily less powerful than those of a Lisp-2. Is that true? Are there some other big advantages of a Lisp-2 that I'm missing?
In article <74e46212-fcd3-4d2d-bc13-f12ac016d...@t1g2000pra.googlegroups.com>,
are <Propon...@gmx.net> wrote: > Having read Touretzky's introduction and the first half of PG's On > Lisp, I'm wondering what the advantages of a Lisp-2 are over a Lisp-1.
> It seems to me that a Lisp-2's ability to use a single symbol to > represent both a function and a value is a minor advantage, although > I'm sure some regard it as a disadvantage. On the other hand, a Lisp-2 > requires the clunky, IMHO, #' operator and cannot have a elegant, > universal DEFINE like Scheme's.
> Yet I've heard that a Lisp-1's macros are necessarily less powerful > than those of a Lisp-2. Is that true? Are there some other big > advantages of a Lisp-2 that I'm missing?
On Jan 10, 1:24 pm, are <Propon...@gmx.net> wrote:
> It seems to me that a Lisp-2's ability to use a single symbol to > represent both a function and a value is a minor advantage, although > I'm sure some regard it as a disadvantage. On the other hand, a Lisp-2 > requires the clunky, IMHO, #' operator and cannot have a elegant, > universal DEFINE like Scheme's.
are wrote: > Having read Touretzky's introduction and the first half of PG's On > Lisp, I'm wondering what the advantages of a Lisp-2 are over a Lisp-1.
> It seems to me that a Lisp-2's ability to use a single symbol to > represent both a function and a value is a minor advantage, although > I'm sure some regard it as a disadvantage. On the other hand, a Lisp-2 > requires the clunky, IMHO, #' operator and cannot have a elegant, > universal DEFINE like Scheme's.
In my personal experience, I have more problems with nameclashes in Scheme (quite often, actually) than in Common Lisp (practically never). A standard (but somewhat silly) example is
(let ((list '(a b c))) ... you can't use the function 'list here anymore in Scheme ...)
But this happens to me in more realistic scenarios...
> Yet I've heard that a Lisp-1's macros are necessarily less powerful > than those of a Lisp-2. Is that true? Are there some other big > advantages of a Lisp-2 that I'm missing?
Lisp-1 macros are not less powerful. You can have macro systems in Scheme that give you the same expressiveness as the Common Lisp macro system (like syntax-case or syntactic closures). With R6RS, you now even have symbol / identifier macros.
However, such so-called hygienic macro systems are, IMHO, much more complicated to use. (They are easier for simple cases, but much harder for complex cases.)
In general, Lisp-2 encourages you to separate namespaces for different concepts, which allows you to have different meanings for the same name in different contexts or for different uses. In contrast, Lisp-1 encourages you to represent concepts as first-class objects. Both approaches have advantages and disadvantages.
Personally, I generally prefer Lisp-2 over Lisp-1 in practical settings, but Lisp-1 has advantages if you want to present the core essentials of an idea. That's probably why Scheme is more widely used in academia than Common Lisp...
Mostly my comments here reply to the inner message, but Rainer added the URL at end which I wanted to keep in and add a comment about.
> In article > <74e46212-fcd3-4d2d-bc13-f12ac016d...@t1g2000pra.googlegroups.com>, > are <Propon...@gmx.net> wrote:
> > Having read Touretzky's introduction and the first half of PG's On > > Lisp, I'm wondering what the advantages of a Lisp-2 are over a Lisp-1.
> > It seems to me that a Lisp-2's ability to use a single symbol to > > represent both a function and a value is a minor advantage,
In understanding things like this, you should worry you are not being objective when your attempt to understand injects "minor" into the data collection rather than the analysis. Just say it's viewed as an advantage, then put the word "minor" into the analysis after the fact. If you're still trying to collect data and also if you aren't speaking to a specific target audience, you can't assess major vs. minor.
I personally consider this issue extremely major.
> > although > > I'm sure some regard it as a disadvantage.
And some would say major disadvantage here, just to underscore my point about how your wording biases you--you are already pre-biasing the outcome by comparing point-by-point rather than by just enumerating the issues and comparing in the context of a known user with particular value scores.
In the metaphor of our world, I think another way to say this is that either: The assessment of point scores needs to be dynamically, not statically, assessed ... or, perhaps, that it's a macro and it's too early to bind the names to values.
I think you are correct here not to add the major/minor qualifier, I'm only pointing out that your decision to say major/minor in one case but not the other is inconsistent.
> > On the other hand, a Lisp-2 > > requires the clunky, IMHO, #' operator and cannot have a elegant,
Elegance is a term that is not canonically defined. Be very careful about this term. There are many forms of elegance. Elegance of language is not the same as elegance of program, for example. Certain members of the Scheme community seem to me to not only have a preference for a single kind of name, but then to take that into the meta to say that the word elegance can only denote a single thing, too. Don't fall into that trap.
I'm not saying Scheme isn't elegant in its own way--I'm saying it does not have a strangehold on the notion of elegance.
Historically, I created the terms lisp1/lisp2 (see below) for the purpose of making this NOT be a battle between Scheme and Lisp, but rather between one particular design principle and another. But, in practice, the people making arguments do come from these communities and tend to have strong allegiances to their own communities which they often don't think through as isolated design choices, but accept sometimes as a necessary whole. At least, in your quest for the Truth (there isn't just one truth either, by the way--that's part of my joke here), make sure to consider this.
> > universal DEFINE like Scheme's.
I'm glad you wrote IMHO, since I don't agree that #' is best described as clunky. It just satisfies a different aesthetic.
Calling #' clunky is like calling the words public/private/protected in other class systems, or calling the ':'/'::' thing in our package system clunky. They increase the number of characters you have to write, but buy something in return.
The question of clunkiness creates an implicit bias in whether you either like the price or value the outcome; and it's legitimate to not like the price or value the outcome, but when assessing the value of something from anything other than a flamewar, you want to make sure to understand that it isn't necessary to something's existence that it satisfy the non-consumers of it, it's necessary that it satisfy the consumers of it. On the other hand, the (effective) adverb IMO or IMHO turns "clunky" as a general claim into "clunky within the non-general framework of one observer", and is then unobjectionable, but loses its scientific basis in the process as a term for describing the feature overall.
In fact, during the design process, and even now, not everyone agreed that functional programming style was what they wanted to do. They weren't trying to make it super-expensive, but they were saying "it doesn't occur often enough that I don't want to see it notated when it happens". So the flip side community actually likes seeing it in many cases, at least for #'foo vs foo, because it flags "this is a function being passed" vs "this is a variable", and that's an important thing to see. In the case of lambda, it's redundant, and Lisp has grown the alternative of allowing you to write either #'(lambda...) or (lambda...) so it's not an issue there.
> > Yet I've heard that a Lisp-1's macros are necessarily less powerful > > than those of a Lisp-2. Is that true?
Lisp1 advocates would likely phrase this in a way that was spun more positively, making side-by-side comparison difficult. In many cases, they will say that the Lisp-1 macro system works reliably and leave it to you to infer that this means the Lisp2 macro system doesn't. It wouldn't under Lisp-1, I think; but they don't have packages, and some in that community think packages make no sense either. But the combination of packages, macros, and normal CL programming style lead to no major problems in practice due to the Lisp2 sytle.
> > Are there some other big > > advantages of a Lisp-2 that I'm missing? > See here:
This published paper is a short form of a longer document we used in the X3J13 process; the longer document is the origin of the terms Lisp1/Lisp2, and at some point it should be dredged up. (As I recall, it didn't have the word "Technical" on its name and had additional arguments that Gabriel wanted to omit during formal publication.)
「Having read Touretzky's introduction and the first half of PG's On Lisp, I'm wondering what the advantages of a Lisp-2 are over a Lisp-1.」
「It seems to me that a Lisp-2's ability to use a single symbol to represent both a function and a value is a minor advantage, although I'm sure some regard it as a disadvantage. On the other hand, a Lisp-2 requires the clunky, IMHO, #' operator and cannot have a elegant, universal DEFINE like Scheme's.」
「Yet I've heard that a Lisp-1's macros are necessarily less powerful than those of a Lisp-2. Is that true? Are there some other big advantages of a Lisp-2 that I'm missing?」
Please try to avoid the jargons lisp1 and lisp2.
Recently i have just wrote a longish essay on the harm of jargons in functional languages.
See
Newsgroups: comp.lang.lisp, comp.lang.scheme, comp.lang.functional From: Xah Lee Date: Wed, 9 Jan 2008 12:20:47 -0800 (PST) Subject: Re: Java as a first language "considered harmful"
The jargon lisp1 and lisp2 is one of better example that illustrate the issue.
★ The jargon is opaque. The words do not convey its meaning.
★ Being a opaque jargon, it is often used subsconsciously by people in a group, to communicate that they are in-group. (a cast- differentiation stratedgy of human animals; as is much of slang's purpose) And consequenctly, these jargons are thrown about often without the writers actually understanding, or wishing to discuss about it in any way.
Further, it is my opinion, this issue is extremely minor, having little real-world practical impact. It is not unlike a war about which end of egg one should crack. (i.e. big endian vs little endian)
Why is this issue minor? Consider it broadly in human animal's computing activities. I give 2 examples:
Consider that in the 1960 people went to moon. Imagine what complexities involved in the physics, mathematics, computation, at a time when computer are some one thousand times slowers than today, using punch-cards, and there are not much computer languages, not even modular programing.
For another example, consider today's PHP language. Linguistically, it is one of the most badly designed language, with many inconsistancies, WITH NO NAMESPACE MECHANISM, yet, it is so widely used that it is in fact one of the top 5 most deployed languages. If one of PHP or lisps and all associated applications written in them is to suddenly disappear from the face of this earth as a catastrophic punishment from Zeus, and all the leaders of nations is to have experts to access the damage as they do with natural disasters, it is probable PHP would be the much greater loss.
-------------
To people in the lisp communities, i would suggest, to stop using the term. If necessary, say Common Lisp's model or Scheme Lisp model.
On Jan 10, 9:10 pm, Xah Lee <x...@xahlee.org> wrote:
> Please try to avoid the jargons lisp1 and lisp2.
> Recently i have just wrote a longish essay on the harm of jargons in > functional languages.
Please stop being a dumb arsehole and a troll. As long as you only post your tripe in separate threads, I can just ignore you, but stop presenting your bullshit as advice to people who might not be able to tell you're deranged.
Maciej
PS. Do you write anything but longish essays? Though hopefully that's a good thing, I'd expect most sane individuals to just tl;dr them, thus minimising the harm done.
Blake McBride wrote: > Kent M Pitman wrote: >> Elegance is a term that is not canonically defined. Be very careful >> about this term. There are many forms of elegance.
> I would define "elegance" as follows.
> One program is more elegant than another that solves the same problem at > least as well but in a simpler manner.
Pascal Costanza <p...@p-cos.net> writes: > Blake McBride wrote: >> Kent M Pitman wrote: >>> Elegance is a term that is not canonically defined. Be very careful >>> about this term. There are many forms of elegance. >> I would define "elegance" as follows. >> One program is more elegant than another that solves the same >> problem at least as well but in a simpler manner.
> Now we only need to define "simple." ;)
"Shorter" is an objective measure, and it is common for "more elegant" approaches to be shorter than "less elegant" approaches.
"Fewer lines" does not usually signal a more elegant mathematical proof, but there's a strong likelihood that "fewer symbols" is suggestive of such... -- output = ("cbbrowne" "@" "linuxfinances.info") http://www3.sympatico.ca/cbbrowne/sgml.html Never lend your car to anyone to whom you have given birth to. --Erma Bombeck
Christopher Browne <cbbro...@ca.afilias.info> writes: > Pascal Costanza <p...@p-cos.net> writes: > > Blake McBride wrote: > >> Kent M Pitman wrote: > >>> Elegance is a term that is not canonically defined. Be very careful > >>> about this term. There are many forms of elegance. > >> I would define "elegance" as follows. > >> One program is more elegant than another that solves the same > >> problem at least as well but in a simpler manner.
> > Now we only need to define "simple." ;)
> "Shorter" is an objective measure, and it is common for "more elegant" > approaches to be shorter than "less elegant" approaches.
Yeah, that's one reason Teco and APL have been so popular.
> "Fewer lines" does not usually signal a more elegant mathematical > proof, but there's a strong likelihood that "fewer symbols" is > suggestive of such...
Certainly... sometimes. But I don't think that if you ask people about elegance without biasing the input, or if you show people various solutions and ask which is most elegant, with a properly distributed set of inputs, that you'll get answers that uniformly say this is so. There is an elegance in Shakespeare, even though I suspect it is not a minimal form. There is language design elegance in Esperanto, and yet people aren't rushing to it o
