I understand that Lisp semantics are based on lists and Scheme semantics are based on Strings. Now can you give me a short concise example where this difference shows in practical terms?
Eran Gatt gave the following example:
<quote> Yes. The canonical example is:
(defun foo () '(1 2 3)) (eq (foo) (foo))
Common Lisp requires this to return T, but the Scheme equivalent is not required to return #T (and indeed there are Scheme implementations that do not return #T). </quote> <!-- sidenote: you see one advantage of XML over S-expr here. Unlike a parenthesis you immediately know what this closing tag refers to -->
The example is good, but it doesn't SEEM to be practically relevant. I'm not saying it isn't.
Can anyone give a simple example where you do some computational task with Lisp that would be much harder to do with Scheme so that the advantage of Lisp becomes more apparent?
thelifter wrote: > Can anyone give a simple example where you do some computational task > with Lisp that would be much harder to do with Scheme so that the > advantage of Lisp becomes more apparent?
In article <b295356a.0309181447.44dbe...@posting.google.com>,
thelif...@gmx.net (thelifter) wrote: > Can anyone give a simple example where you do some computational task > with Lisp that would be much harder to do with Scheme so that the > advantage of Lisp becomes more apparent?
(defmacro compile-time-factorial (n) (if (numberp n) (if (and (integerp n) (> n 0)) (factorial n) (error "Can't take the factorial of ~S" n)) (if (or (symbolp n) (listp n)) `(factorial ,n) (error "Can't take the factorial of ~S" n))))
>> Can anyone give a simple example where you do some computational task >> with Lisp that would be much harder to do with Scheme so that the >> advantage of Lisp becomes more apparent?
> The judicious use of macros, especially in the pseudo.lisp > implementation allows easy translation of the URI BNF > syntax to a lisp like representation.
> Wade
If you want the supporting code to run uri.lisp see
system.lisp contains the package definitions for uri and pseudo as well as other sundry LW system definitions. I assume the uri code will run on any compliant CL.
> </quote> <!-- sidenote: you see one advantage of XML over S-expr here. > Unlike a parenthesis you immediately know what this closing tag refers > to -->
1) No, you may just have nested tags with same name, in which case you still need to refer to the indentation or count the tags.
2) With s-expr you also immediately know what parentheses correspond to, and that's all handled by your editor.
Really, other than being an industry standard, I don't see any advantage to XML compared to s-expr.
>> Can anyone give a simple example where you do some computational task >> with Lisp that would be much harder to do with Scheme so that the >> advantage of Lisp becomes more apparent?
> (defmacro compile-time-factorial (n) > (if (numberp n) > (if (and (integerp n) (> n 0)) > (factorial n) > (error "Can't take the factorial of ~S" n)) > (if (or (symbolp n) (listp n)) > `(factorial ,n) > (error "Can't take the factorial of ~S" n))))
>> Can anyone give a simple example where you do some computational task >> with Lisp that would be much harder to do with Scheme so that the >> advantage of Lisp becomes more apparent? >> Thank you very much...
> The judicious use of macros, especially in the pseudo.lisp > implementation allows easy translation of the URI BNF > syntax to a lisp like representation.
thelif...@gmx.net (thelifter) writes: > /quote> <!-- sidenote: you see one advantage of XML over S-expr here. > Unlike a parenthesis you immediately know what this closing tag refers > to -->
Wrong. If you have multiple <quote> or whatever tags, you can't tell anything without a smart editor. In this case XML is the _worst_ of all possible worlds. You have all this heavy <....> tag crap but it doesn't go the extra mile and require the tags to be labeled and so it's all for nothing.
Worse yet, a smart editor harder to write and it's brittle - you need to know the "syntax" of all this crappy tag stuff and if some idiot at W3C adds some more tags or attributes, you need to _change_ your editor or it will no longer work. Really, anyone who thinks there is any advantage of XML in any sense for anything is really lost and is part of the current _problems_ with software, not any solution.
thelif...@gmx.net (thelifter) writes: > Can anyone give a simple example where you do some computational task > with Lisp that would be much harder to do with Scheme so that the > advantage of Lisp becomes more apparent?
Can someone give an example of a driving task that is much harder to do with an American car than a Japanese or German car? Yet some people strongly prefer one to the other, and not just for reasons of national pride. There are material design details that really matter to people even though if you examine any one of them in isolation someone will always make some plausible argument about why they are really equivalent. The same is true about wine and beer choices, or even coke vs pepsi.
The reason I say this is that there is an apparent subtext of the question quoted here which is "If no one does, I'm going to conclude that this doesn't matter as much as people say and that they're just making it up." You came close to doing that that earlier in the same post by saying:
> The [equality of literals] example is good, but it doesn't SEEM to be > practically relevant. I'm not saying it isn't.
The "I'm not saying it isn't." seems to be more a disclaimer in case you're wrong than a legitimate statement of your feelings, which I worry is that you're dismissing the issue.
The thing that makes the issue practically relevant is that it occurs "in the large". Someone has cited a small example so it's easy to talk about, not because the same issue doesn't happen in larger contexts. It's just harder to describe because it involves really a lot of code. I started to sketch an example but even the sketch quickly became bigger than I had the time or patience to set up. Sigh. I'm not saying this is the only difference between Scheme and Lisp, nor even The criterial one, but I think it's an important one. And that saying "oh, there's a mapping" misses the point. In fact, it weirds me out given how much more "mathematical" the Scheme community seems to be than the Lisp community (preferring "formal semantics" and all kinds of otehr stuff like that with greek symbols all over) that people will use a term like mapping without the important modifiers "many to one" or "one to many" and be willing therefore to hide the loss of information that occurs in that mapping, and the significance of making compilation be based on objectness. Hygienic macro systems notwithstanding, the meaning of (eval `(eql 'foo ',(copy-symbol 'foo))) in scheme, that is, the meaning of using a gensym in code, is not well-defined. That seems significant to me linguistically in a language that purports to be [original meaning] object-oriented, that is, about objects (rather than program texts).
Joe Marshall <j...@ccs.neu.edu> writes: > g...@jpl.nasa.gov (Erann Gat) writes:
> > In article <b295356a.0309181447.44dbe...@posting.google.com>, > > thelif...@gmx.net (thelifter) wrote:
> >> Can anyone give a simple example where you do some computational task > >> with Lisp that would be much harder to do with Scheme so that the > >> advantage of Lisp becomes more apparent?
> > (defmacro compile-time-factorial (n) > > (if (numberp n) > > (if (and (integerp n) (> n 0)) > > (factorial n) > > (error "Can't take the factorial of ~S" n)) > > (if (or (symbolp n) (listp n)) > > `(factorial ,n) > > (error "Can't take the factorial of ~S" n))))
> (if (number? n) > (if (and (integer? n) (> n 0)) > (factorial n) > (error "Can't take the factorial of " n)) > (if (or (symbol? n) (list? n)) > `(factorial ,n) > (error "Can't take the factorial of " n))))
Wouldn't it be more fun to write just plain old factorial and then a compiler-macro for it? Scheme doesn't have compiler macros and the facility is hard to simulate.
Not that this is itself a "deep" problem with Scheme. The deep problem, I think, is better expressed as "Scheme's lack of consideration for the many different `times' that decisions are made." That is, the collective absence of #., eval-when, load-time-value, define-compiler-macro, etc. are more of a collective concern and more of an indication of overall differences in politics/philosophy than any given one of those. The fact that they have "other ways" of addressing one or more of them isn't really a "fix" for this claim, since the issue isn't "what can be computed" but "how". We already know from Turing that "what can be computed" is not in question; the only difference is ever "how" and whether two dialects/languages/language families are either "mostly alike" or "hardly alike". So unless the answer is "you missed eval-when. it's on page 47." then the answer is "you're right, they're different on these important points"... unless you think these points are unimportant. and then we disagree as well...
I'm speaking to the generic "you" here, not necessarily to Joe.
Mario S. Mommer wrote: > Joe Marshall <j...@ccs.neu.edu> writes: > > (require (lib "defmacro.ss"))
> > (defmacro compile-time-factorial (n)
> Oh my, how /unhygienic/!!
> You are cheating and you know it.
Why? The original question asked for a demonstration of how the claim that "Lisp semantics are based on lists" has practical relevance. The provided answer didn't address that issue at all, and Joe Marshall's Scheme version of the same macro demonstrates this. Note that defmacro can be implemented in terms of syntax-case, a portable Scheme macro system.
> The thing that makes the issue practically relevant is that it occurs > "in the large". Someone has cited a small example so it's easy to talk > about, not because the same issue doesn't happen in larger contexts. > It's just harder to describe because it involves really a lot of code. > I started to sketch an example but even the sketch quickly became > bigger than I had the time or patience to set up. Sigh.
That is why I posted my larger URI example. It involves using
packages - I did not have to worry about name conflicts special variables - for parsing context macros - compactified the code by creating a mini language clos - creating a uri type conditions - to signal parsing errors property lists - used in the grunt parsing work
Alone the power of each is not obvious, but used together, in real coding situations, there is no standard analog in Scheme. It would just be more difficult. Even renaming each function in the pseudo and uri packages would take more thought and effort in (Standard) Scheme to accomplish.
Erann's defmacro example is analogous to this macro in the pseudo package, same problem and less contrived.
> Jens Axel Søgaard <use...@jasoegaard.dk> writes: >> Mario S. Mommer wrote: >> > Joe Marshall <j...@ccs.neu.edu> writes:
>> >>(require (lib "defmacro.ss"))
>> >>(defmacro compile-time-factorial (n) >> > Oh my, how /unhygienic/!!
>> Where? The factorial is local to >> the compile-time-factorial function.
> Splitting hairs, eh? :-)
> Wasn't the party line over at c.l.s that cl's defmacro is broken > because it is not "hygienic"?
I wouldn't say characterize that as the `c.l.s party line'.
A CL defmacro clearly isn't broken in the context of CL.
A CL-type macro in a Scheme context, however, cannot be guaranteed to not inadvertantly capture bindings. If you want or need that kind of a guarantee, then you'll need some sort of variable renaming that CL macros cannot do.
Non-hygienic Scheme macros have been around for longer than Common Lisp has, but since a canonical implementation couldn't be agreed upon, the report never included them.
> Wouldn't it be more fun to write just plain old factorial and > then a compiler-macro for it? Scheme doesn't have compiler > macros and the facility is hard to simulate.
> Not that this is itself a "deep" problem with Scheme. The deep > problem, I think, is better expressed as "Scheme's lack of > consideration for the many different `times' that decisions > are made."
I think it isn't really a lack of consideration, but a lack of agreement amongst the various scheme implementors.
> I'm speaking to the generic "you" here, not necessarily to Joe.
Kent M Pitman wrote: > In fact, it weirds me out given how much more "mathematical" the > Scheme community seems to be than the Lisp community (preferring > "formal semantics" and all kinds of otehr stuff like that with greek > symbols all over)
Kent, you are really scraping the bottom of the barrel.
van Straaten" <an...@appsolutions.com> wrote: > Mario S. Mommer wrote: > > Joe Marshall <j...@ccs.neu.edu> writes: > > > (require (lib "defmacro.ss"))
> > > (defmacro compile-time-factorial (n)
> > Oh my, how /unhygienic/!!
> > You are cheating and you know it.
> Why? The original question asked for a demonstration of how the claim that > "Lisp semantics are based on lists" has practical relevance. The provided > answer didn't address that issue at all, and Joe Marshall's Scheme version > of the same macro demonstrates this. Note that defmacro can be implemented > in terms of syntax-case, a portable Scheme macro system.
Note that the OP asked for an example that was made easier by Lisp's treatment of programs as lists, not an example that was made possible by it. If you actually go and write the code for compile-time-factorial using syntax-case it will become quite clear that my example is in fact on point.
(define-macro is not a part of the Scheme standard. It is provided by many Scheme implementations because, of course, Scheme does not *prohibit* programs from being represented as lists, but neither does it require them to be so, and so you cannot count on having define-macro at your disposal.)
"Anton van Straaten" <an...@appsolutions.com> writes:
> Kent M Pitman wrote: > > In fact, it weirds me out given how much more "mathematical" the > > Scheme community seems to be than the Lisp community (preferring > > "formal semantics" and all kinds of otehr stuff like that with greek > > symbols all over)
> Kent, you are really scraping the bottom of the barrel.
Perhaps for descriptive prose, but I think my point in general is true. If someone disagrees, I'd be curious. It seems to me like people who self-identify as mathemeticians tend toward Scheme and people who self-identify as engineers or practioners of some applied science tend toward CL, for exactly the same reasons that Scheme has a stronger bias toward aesthetics in design and CL has a stronger bias toward practicality in design. I certainly have no concrete data on this, but I've observed a lot of personal preferences over the years and haven't heard too many complaints from people I have steered one way or another in a triage setting where they were seeking to learn one or the other language and I used this criterion. I'm open to claims that this is not the nature of the partition, but I'd be curious along with this to hear what the nature of the partition is... since that's what the thread topic is, after all.
On 19 Sep 2003 15:00:39 -0400, Kent M Pitman <pit...@world.std.com> wrote:
> It seems to me like people who self-identify as mathemeticians tend > toward Scheme and people who self-identify as engineers or > practioners of some applied science tend toward CL, for exactly the > same reasons that Scheme has a stronger bias toward aesthetics in > design and CL has a stronger bias toward practicality in design.
Just to provide one data point: I'm a mathematician who specialized in pure mathematics (logic and set theory). I have a strong bias towards Common Lisp. But maybe that's because I'm working as a free-lance developer since 1997 or so.
Kent Pitman wrote: > Perhaps for descriptive prose, but I think my point in general is true. > If someone disagrees, I'd be curious. It seems to me like people who > self-identify as mathemeticians tend toward Scheme and people who > self-identify as engineers or practioners of some applied science > tend toward CL, for exactly the same reasons that Scheme has a stronger > bias toward aesthetics in design and CL has a stronger bias toward > practicality in design.
I'm a mathematician (and by training and preference a pure mathematician, though what I get paid for is more applied), and I prefer CL. I do feel the aesthetic appeal of Scheme, but ... well, programming languages are primarily for programming in :-).
> Wrong. If you have multiple <quote> or whatever tags, you can't tell > anything without a smart editor. In this case XML is the _worst_ of > all possible worlds. You have all this heavy <....> tag crap but it > doesn't go the extra mile and require the tags to be labeled and so > it's all for nothing.
If not for XML, some things about s-ex's would have eluded me. For example, should nodes and attributes share the same namespace? On first glance, that sounds absurd. That gives insight into the lisp-2 debates; coming from certain complicated OOP languages, one doesn't always appreciate how separate functions are from everything else, as means of combination.
But also, if I had only Windows notepad to edit small bits of text, which would I prefer it in: XML or s-ex's? Generally I'd prefer XML.
When people argue that one just needs a decent IDE for s-ex's, does that actually imply XML just doesn't have great IDE support yet? I should neither need to think about closing tags nor close-parens.
> "Anton van Straaten" <an...@appsolutions.com> writes:
> > Kent M Pitman wrote: > > > In fact, it weirds me out given how much more "mathematical" the > > > Scheme community seems to be than the Lisp community (preferring > > > "formal semantics" and all kinds of otehr stuff like that with greek > > > symbols all over)
> > Kent, you are really scraping the bottom of the barrel.
> Perhaps for descriptive prose, but I think my point in general is true. > If someone disagrees, I'd be curious. It seems to me like people who > self-identify as mathemeticians tend toward Scheme and people who > self-identify as engineers or practioners of some applied science > tend toward CL, for exactly the same reasons that Scheme has a stronger > bias toward aesthetics in design and CL has a stronger bias toward > practicality in design. I certainly have no concrete data on this, but > I've observed a lot of personal preferences over the years and haven't > heard too many complaints from people I have steered one way or another > in a triage setting where they were seeking to learn one or the other > language and I used this criterion. I'm open to claims that this is not > the nature of the partition, but I'd be curious along with this to hear > what the nature of the partition is... since that's what the thread > topic is, after all.
Kent,
I am a mathematician by training, and I was definitely more attracted toward Scheme than Common Lisp. The minimal simplicity and elegance is very appealing to a mathematican. After awhile I thought I should take a look at Common Lisp. When I did, I found it that it seemed ugly by comparison. Normally, that would be the end of the story, but I was also doing software engineering and had a strong desire to find better languages to work with. I eventually reexamined Common Lisp and realized that this was a serious industrial strength language with features developed by people working on nasty problems. It is now hard for me to imagine going back to Scheme.
I am also from a Pure Mathematics background. Even in mathematics the world is a messy place, many thereoms use "tricks" or "klunges" to get the work done. I definitely prefer CL.
