> > Maybe CL critiques of Scheme should proceed more along the lines of > > "Scheme is just a Lisp" rather than "Scheme is not a Lisp". :-/
> But why should we, or anyone else, tie down scheme to being "just a > lisp"? Let the scheme community do what they want, but don't define > scheme as a "superior lisp". I just don't see the point in scheme > clinging to the name "lisp" when the point of the name scheme was so > that it wasn't percieved as lisp!
If they so wanted to avoid the perception of association with Lisp, they obviously didn't do a very good job of writing the standard.
After all, after, if what you suggest is true, namely that they intended dissociation from Lisp, they broke that in the second sentence of the standard by describing Scheme as a "dialect of the Lisp programming language."
Kinda stupid to have the goal of dissociation and then start the standard by describing how it's an instance of a Lisp... -- (concatenate 'string "cbbrowne" "@acm.org") http://www.ntlug.org/~cbbrowne/ Rules of the Evil Overlord #26. No matter how attractive certain members of the rebellion are, there is probably someone just as attractive who is not desperate to kill me. Therefore, I will think twice before ordering a prisoner sent to my bedchamber. <http://www.eviloverlord.com/>
> Hygenic macros solve a problem that CL does not have. > (They solve a problem introduced by Lisp1-ness. Heh.) > I see no need for these whatsoever.
* Thomas Bushnell, BSG | Hrm, maybe this is true, but I'm not sure about it. There is a root | problem that I think CL still has, but maybe not. Requires more thought | before I'd be confident either way. (And another close read of Chris | Hansen's paper.) But maybe you could say why you think the problem | exists in Scheme but not CL?
Briefly put, the single namespace means that any variables used by the macro would cause any user-defined functions with the same name to become unusable in the body of the macro. This requires a solution, and the solution is both real symbols, packages, and two namespaces, but in Scheme, they held on to the single namespace and had to invent hygienic macros, instead. In Common Lisp, there is no danger of trampling on the functional value of a symbol just because you bind it lexically as a variable, so the body of the macro is undisturbed by any overlap in usage. Also, since we have the ability to generate a symbol that cannot be reached by any name by the reader -- it is not interned in any package -- using either make-symbol or gensym, we have a choice of exporting a variable (or even function) from the macro to the body or to hide it with an invisible symbol. Using such generated symbols poses no worse problems for any competent programmer than writing hygienic macros. There are even macros around that "rebind" variables hygienically.
Thus hygienic macros is a necessary solution to a problem that arose from several bad design decisions in Scheme that plague the language in more ways than just requiring hygienic macros -- at least as seen from Common Lisp. The single namespace, the lack of first-class symbols, exacerbated by the lack of packages, and the need for make-shift solutions to what should not have been problems, are all among the things that will continue to create problems. Scheme therefore has to return to the drawing board and redesign itself instead of dragging this bggage along into the future. At least it should try again with first-class symbols and packages.
/// -- 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.
Was any of that *not* exactly the same kind of thing you said you *don't* want here, at least, not when the languages are reversed?
It's so filled with mindless boosterism, the technical content is almost absent. But, taking a gander at the technical content, the issue in your mind seems to be shadowing of global function names.
Can't the same thing happen with shadowing of top-level variable names?
(As for the gensym issue, of course, gensym-like-solutions are exactly how Scheme implementations implement hygenic macros.)
> Kent M Pitman <pit...@world.std.com> writes: ... > > The basic concept is to clip the effect of call/cc so that it closes over > > only a certain amount of the pending "stack", not everything back to > > creation.
> Oh, I understand; yeah that's a reasonable desire. I still wonder (no > need to answer if you don't like), what's the reason? It sounds like > an efficiency tweak, but I wonder what the semantic advantages would > be. I'll look up and see if I can find an answer myself, but I'd > appreciate pointers if anyone has some.
It has to do with externalization.
I used to see the Actor stuff that Henry Leiberman would use at the MIT AI Lab printing out continuations to hand to objects in other machines. The problem is that this exposes internal details of the running image that go beyond the scope of the task to be performed... Plus there are some conceptual issues that have to do with GC that get involved, too, I think. I've not thought about it in a while so my brain may be fuzzy on the details.
* Thomas Bushnell, BSG | Except there hasn't been such "pathetic whining", except for your | amazing diatribes. It would be funny if it weren't so sad.
I am saddened that you are so deep into denial that you cannot even see what you are doing. Please seek help to get out your anger rut. At the very least, take a break from this newsgroup for a couple weeks. You are too wound up to be able to think unclouded by emotion, and this does you no good. You need to learn to deal with both diversity of opinion and the adversity of rejection of your opinions. I also suggest you talk to someone about how you cope with cognitive dissonance. Quit lying about me and what I say, want, or intend, and there is no need for me to post any correctives to your lies, either. Now is a good time for you to zoom out and think carefully about what you want. In case it is not clear: I want you noise-polluting Scheme freaks out of here, because there is very strong evidence of a serious culture clash whenever any one of you have the bad taste to wander into this forum or cross-post here. And please, it is not because we do not handle disagreement -- we have plenty of it -- it is because you cannot deal with us being right and you being wrong in this newsgroup even if you have always been patted on the back and got the best grades for what you parrot from another forum. If technical issues matter, if decisions of language design are made on technical grounds, and if call-with-current-continuation is a technically superior idea, how come no other language has this construct? Either you have to face that "technical" does nto matter, or that this feature is no good. That is a question you do not receive where everybody agrees it is the best thing since sliced bread and there is something wron with the rest of the world for not having it, but that agreement does not exist here. It is such things that make up the reasons for splitting a community. Again, it is not because people cannot handle disagreement, it is just that some things are supposed to be agreed upon in a community -- they are precisely what the community is based on, it is because people agree on these things even though they disagree on a lot of others that they have come together. Even if people fight all the time for what they think is right, there is serious psychological value in coming home to someone who love you for who you are and not have to fight. That is what normal people seek in a reasonable community -- a place where people agree with them on certain things. For instance, if people have to fight for their desire to use Common Lisp all day long and they have to face stupid and prejudiced people who denigrate Lisp and make their lives so much less enjoyable, they would naturally want to come to comp.lang.lisp and find people who agree with them that Common Lisp is a great language -- but that is precisely what you fucking annoying Scheme freaks deny us, what those who have some idiotic gripe with the standard deny us, what those who post web pages whining about braindamaged conditionals deny us, etc. There are just some decisions we have made, we agree on them and their outcome, and we do not want to fight that battle over and over and over just because some of those who have not made that decision and who have their own forum to feel safe and secure in, choose to invade us with a constant barrage of annoying attitude problems. I find you stupid dorks incredibly inconsiderate and rude, and I respodn to your total lack of civility in storming a political party meaning, or a church, or an abortion clinic, or a radio or TV station, or a newsgroup, with an agenda that basically says: "You guys are all wrong, and we are going to convert you!" Such idiotic wars is not what technical newsgroups are for. If you Scheme freaks want this kind of forum, I suggest you create a new forum, comp.lang.lisp.advocacy, where fools can bash eachothers' heads in, while adults can explore the space that opens up before them because they are comfortable with having made a particular decision.
(I made that all one paragraph so people who read only the first should not get away with skipping all the juicy bits.)
/// -- 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.
> Was any of that *not* exactly the same kind of thing you said you > *don't* want here, at least, not when the languages are reversed?
> It's so filled with mindless boosterism, the technical content is > almost absent. But, taking a gander at the technical content, the > issue in your mind seems to be shadowing of global function names.
> Can't the same thing happen with shadowing of top-level variable > names?
No, it can't. If the variable is in the same package and you shadow it, then you presumably meant to. In general the only top level variables in CL are specials, and one doesn't bind them without a purpose.
Good style in macros is never to reference any variables free except those named by the macro caller or except specials or except variables you document that you will capture.
> (As for the gensym issue, of course, gensym-like-solutions are exactly > how Scheme implementations implement hygenic macros.)
That's not really true. Not the same gensyms as in CL. That is, in hygiene systems involving painting, symbols are painted without regard to whether they are going to need to be gensymed, and list structure identity is violated without regard to whether it is literal quoted lists or semantically meaningful programs. Lots more gensyms are made than are needed.
Sometimes people say this doesn't matter. But I find it to be the same kind of doesn't matter as "it doesn't matter if the police search your house when you're out for the day. as long as you're doing nothing illegal, they will leave it as they found it, and it will not matter that they were there". To me, it does matter. Among other things, it exposes the processed program text to bugs due to errors in the "doesn't matter" processing, just as my delicate glass objects are exposed to risk if the police screw up and bump a table they shouldn't while they're making a "doesn't matter" search of my house.
While working on T in 1981, I had prototyped a solution to this which I never got to publishing. A couple years later, Bawden came up with and did publish more or less the same idea as I had been working on and even gave it a nice name (I think it was called "syntactic closures" ...?) but the Scheme community did not go in that direction. They went with the Kohlbecker painting solution instead, which I don't endorse.
* Thomas Bushnell, BSG | Was any of that *not* exactly the same kind of thing you said you *don't* | want here, at least, not when the languages are reversed? | | It's so filled with mindless boosterism, the technical content is almost | absent.
Take a long break, will you? Your mind is no longer able to deal with the _purpose_ that a normal, rational, sane person would have in reading and posting to a technical newsgroup. Just get rid of your anger. It is misplaced and counterproductive, and you have become so hypersensitive to what you perceive as hostilities that you completely fail to understand that you are by now _causing_ most of it.
If you want people to agree with you that Scheme is such a great language, when it clearly is not _universally_ so, comp.lang.scheme should be your chosen forum. Ov here, where there is no such "safe heven" from criticism, you just have to learn to cope with rejection of your core beliefs or get the hell out of here. Scheme is _not_ protected from criticism in this forum. When someone thinks Scheme sucks so bad it used to be abolished, they are likely to say so here, but _not_ in comp.lang.scheme, because that would be trolling. This should not a big issue -- it is how all human forums works. You guys should just figure out that your local belief that "Scheme is a superior Lisp" is _false_ in comp.lang.lisp, even though it is the raison d'être for comp.lang.scheme and therefore am unquestioned truth there.
But take long a break, Thomas Bushnell! You really _need_ it, now. Find your way back to whatever desire or purpose prompted you to read and post to comp.lang.lisp. This is not a proper forum for venting your spleen about anyone. You, of all people, should know that, being as you wave the "charter" and want to control what is permissible here.
/// -- 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.
> No, it can't. If the variable is in the same package and you shadow it, > then you presumably meant to. In general the only top level variables > in CL are specials, and one doesn't bind them without a purpose. > Good style in macros is never to reference any variables free except those > named by the macro caller or except specials or except variables you > document that you will capture.
Um, so it sounds like the answer is "yes, it *does* happen with top-level variables, but because of style and packaging considerations, no problems actually come up". (Which is a perfectly good explanation; given that fact, I agree that CL doesn't really need a hygenic macro system the way Scheme does.
> [In Scheme] > Lots more gensyms are made than are needed.
Indeed, this is true; I think the expectation is that optimizing compilers will notice the unused gensyms and elide them cleanly. (Whether that is done in practice or not is something I don't really know.)
> They went with the Kohlbecker painting solution instead, which I don't > endorse.
Isn't that just one implementation strategy? I thought there were several quite different underlying implementations possible (and in use), with painting being only one of the alternatives. (I'm close to the extent of my depth here, so forgive my ignorance if the answer is obvious.)
> I think that if scheme is a lisp, then it would be a very strange > concept to call ML not a lisp. ML and Scheme are on oppposite ends of > one spectrum (static typing) that Common Lisp is in the middle > of. However, in most other regards, ML can pretty much be considered > to be closer to scheme than it is to common lisp.
Scheme and ML fail my "Can you easily transliterate textbook programs from one language into the other language?" test. Scheme examples make frequent use of runtime polymorphism. ML examples make frequent use of implicit currying.
> > I'm a bit unclear about the "notation for functions in terms of > > conses" requirement, also.
> I think he basically means that code is expressed as cons-trees.
I don't see why that is important for languages that don't have "eval" or procedural macros, such as ML, Dylan, and (believe it or not) Scheme until recently.
* Christopher Browne | If they so wanted to avoid the perception of association with Lisp, | they obviously didn't do a very good job of writing the standard.
It serves a standard well to be accurate about its heritage (which I have pointed out that it is not, ironically). There is no point in talking about it when teaching the language, because those who are learning it are most probably not aware of what the heritage means in the first place -- and if you have paid attention, you will notice that such historical things as language families is not foreign to me, but confused marketing is _the_ issue.
I note in passing that the Dylan Reference Manual completely avoids any reference to Lisp. Whatever some propagandists think, this can be used to send them on their way back to comp.lang.dylan. How useful!
I note in passing that reading the RnRS documents is not what _I_ would recommend anyone to do who were not ready to understand a lot more than they need to program in it.
| After all, after, if what you suggest is true, namely that they intended | dissociation from Lisp, they broke that in the second sentence of the | standard by describing Scheme as a "dialect of the Lisp programming | language." | | Kinda stupid to have the goal of dissociation and then start the standard | by describing how it's an instance of a Lisp...
Only if you have only one-bit answers.
/// -- 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.
> Some things that CL might profitably borrow from Scheme would be > proper tail recursion
if only anyone could define what is "proper" on all concievable platforms.
> and hygenic macros.
That's been done by Dorai Sitaram, "macros by example".
-- -> -/ - 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.
> > Some things that CL might profitably borrow from Scheme would be > > proper tail recursion
> if only anyone could define what is "proper" on all concievable > platforms.
Um, is there really a problem here? Proper tail recursion is defined in terms of the space complexity of the computation. You have to give a careful definition of which syntactic contexts count as a "tail call".
The Scheme standard requires that an unbounded number of active tail calls must be supported; there may be other ways of saying the same idea.
According to the Scheme standard, a more formal definition is in the paper:
William Clinger. Proper Tail Recursion and Space Efficiency. To appear in Proceedings of the 1998 ACM Conference on Programming Language Design and Implementation, June 1998.
> If this last remark were true, it would imply that the inventor > of Lisp holds opinions that imply that CL is not in the Lisp > family.
I think that CL is different enough from the original LISP that it _could_ be considered a different language. Just like C99 could be considered a different language than K&R C, but even more so. But the issue is that the CL community traces direct lineage to the original LISP community, and as Kent has repeatedly claimed, that's what matters when defining what a language is and is not. Scheme is a "fork" from that community of people who wanted very different things than what the mainstream Lispers wanted.
> Let me hasten to add that, in my opinion, CL is indeed within > the Lisp family of languages, and that I strongly suspect that > John McCarthy holds a similar opinion.
Yes, I think that's true more because of the reasoning I gave above than any feature list.
While McCarthy's list is a nice summary of the ideas he considers essential to a Lisp, it doesn't by any means cover what others want from Lisp nor what distingushes Lisp from anything else.
Personally, I require at least symbols with packages, complete macros, compiler macros, an object system with various features I won't enumerate here, reader macros, and conditions from a Lisp. But I don't bother trying to rigorously define what is a Lisp because I know that categories in natural language are fuzzy.
-- -> -/ - 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.
Christopher Browne <cbbro...@acm.org> writes: > Kinda stupid to have the goal of dissociation and then start the > standard by describing how it's an instance of a Lisp...
Right, that's what confuses me. But it is clear from the actual description and community of scheme that they definitely didn't want to be a subset of the Lisp community.
-- -> -/ - 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.
> Rahul Jain <rj...@sid-1129.sid.rice.edu> writes: > Um, is there really a problem here? Proper tail recursion is defined > in terms of the space complexity of the computation. You have to give > a careful definition of which syntactic contexts count as a "tail > call".
You can search google groups for past discussions about what can and cannot be considered a tail call. There was no conclusion.
-- -> -/ - 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.
Bruce Hoult <br...@hoult.org> writes: > In article <87vgbyz9jo....@photino.sid.rice.edu>, > Rahul Jain <rj...@sid-1129.sid.rice.edu> wrote: > > Bijan Parsia <bpar...@email.unc.edu> writes: > > > Is ML a Lisp? > > I think that if scheme is a lisp, then it would be a very strange > > concept to call ML not a lisp. ML and Scheme are on oppposite ends of > > one spectrum (static typing) that Common Lisp is in the middle > > of. However, in most other regards, ML can pretty much be considered > > to be closer to scheme than it is to common lisp. > Scheme and ML fail my "Can you easily transliterate textbook programs > from one language into the other language?" test.
So the syntax is what matters? Java is a C, then? And what textbook are you talking about? I can't believe that there are textbooks which don't use call/cc and there should be textbooks which use CL's condition system, and there are surely ones that use throw/catch. I don't consider throw/catch to call/cc to be an "easy" transformation.
> Scheme examples make frequent use of runtime polymorphism.
Right, that's the static typing axis.
> ML examples make frequent use of implicit currying.
That's syntactic sugar, really.
> > > I'm a bit unclear about the "notation for functions in terms of > > > conses" requirement, also. > > I think he basically means that code is expressed as cons-trees. > I don't see why that is important for languages that don't have "eval" > or procedural macros, such as ML, Dylan, and (believe it or not) Scheme > until recently.
Yes, exactly. :)
-- -> -/ - 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.
Erik Naggum <e...@naggum.net> writes: > * Christopher Browne > | Kinda stupid to have the goal of dissociation and then start the standard > | by describing how it's an instance of a Lisp...
> Only if you have only one-bit answers.
Hmm, yes. But it would have made more sense for them to make clear that they were on a trajectory away from Lisp.
-- -> -/ - 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.
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes: > You can search google groups for past discussions about what can and > cannot be considered a tail call. There was no conclusion.
Oh, indeed; like I said, you must carefully determine what counts as a tail call. That is indeed fraught with difficulties.
But you asked about what could be considered "proper", instead of what could be considered a "tail call". The proper part is easy and unambiguous. The tail call part is not.
There are certain things you might think are tail contexts in Scheme where the R5RS does not require proper tail recursion, for example.
Adding proper tail recursion to Common Lisp would require such careful work too.
Rahul Jain <rj...@sid-1129.sid.rice.edu> writes: > Right, that's what confuses me. But it is clear from the actual > description and community of scheme that they definitely didn't want > to be a subset of the Lisp community.
Really? When the description says "Scheme .. is a dialect of the Lisp programming language", you think that makes it clear they don't want to be a subset of the Lisp community? Every Scheme description I have ever seen says something like that, and you conclude that they *definitely* don't want to be part of the Lisp community?
Indeed, even the Common Lisp language texts list Scheme as a dialect of Lisp.
What is it that is making your conclusion so clear to you?
> > In article <87vgbyz9jo....@photino.sid.rice.edu>, > > Rahul Jain <rj...@sid-1129.sid.rice.edu> wrote: > > > Bijan Parsia <bpar...@email.unc.edu> writes: > > > > Is ML a Lisp?
> > > I think that if scheme is a lisp, then it would be a very strange > > > concept to call ML not a lisp. ML and Scheme are on oppposite ends of > > > one spectrum (static typing) that Common Lisp is in the middle > > > of. However, in most other regards, ML can pretty much be considered > > > to be closer to scheme than it is to common lisp.
> > Scheme and ML fail my "Can you easily transliterate textbook programs > > from one language into the other language?" test.
> So the syntax is what matters? Java is a C, then?
No, syntax does not matter. For example, Common Lisp and Dylan can usually be easily transliterated into each other, but the syntax is quite different.
> And what textbook are you talking about? I can't believe that there > are textbooks which don't use call/cc
As someone just pointed out, SICP doesn't mention call/cc. I hadn't realised that, but SICP is pretty much the clasic textbook-that-uses-scheme.
> and there should be textbooks which use CL's > condition system, and there are surely ones that use throw/catch. I > don't consider throw/catch to call/cc to be an "easy" transformation.
I wouldn't either. CL and Scheme aren't very close in this area. On the other hand, CL and Dylan have very similar condition systems -- Dylan unifies conditions and restarts but that's more a theoretical tidiness thing than a practical problem.
> > Scheme examples make frequent use of runtime polymorphism.
> Right, that's the static typing axis.
> > ML examples make frequent use of implicit currying.
> That's syntactic sugar, really.
True, and you can emulate it in Scheme using lambdas and/or an explicit "curry", but it's used heavily enough in ML to cause a lot of code expansion when translated to Scheme.
Perhaps a better example (which I mentioned yesterday but forgot today) is the heavy use of pattern matching in ML.
> > > > I'm a bit unclear about the "notation for functions in terms of > > > > conses" requirement, also.
> > > I think he basically means that code is expressed as cons-trees.
> > I don't see why that is important for languages that don't have "eval" > > or procedural macros, such as ML, Dylan, and (believe it or not) Scheme > > until recently.
> Yes, exactly. :)
Well, if you think that "eval" is essential then list *it*, not the incidental "notation for functions in terms of conses".
> In article <3C90CDAD.E3592...@cfmu.eurocontrol.be>, > Ian Wild <ian.w...@eurocontrol.int> wrote: > >Dorai Sitaram wrote:
> >> In article <4f52f844.0203140725.2b0bd...@posting.google.com>, > >> Paul Graham <s...@bugbear.com> wrote: > >> >If a language has car, cdr, cons, if, eq, atom, quote, and a > >> >notation for functions in terms of conses, then it's Lisp.
> >> In addition to your list (!), I would add I/O > >> procedures -- read, prin1/write, and at least one > >> of {load, eval} -- that operate directly on s-exps.
> >That would mean you could /never/ have an embedded Lisp.
> I'm sorry I didn't understand that. Is an "embedded > Lisp" something that has an s-exp syntax but doesn't > have read, prin1, etc? Does this Lisp system have > ports (in the sense of doors) to the outside > world at all, and how does it accept a Lisp program to > run?
Err....I feed my program to the compiler and it generates the bytes that get burned into ROMs that make the doorbell play the opening sequence of "All You Need is Love". I can write my program in a choice of languages, assembler, C, and PL/M spring to mind, but you're suggesting I can /never/ use Lisp unless I also fit a screen and keyboard to the doorbell. (Plus, I'd guess, a disc drive to give "load" somewhere to look.)
> Really? When the description says "Scheme .. is a dialect of the Lisp > programming language", you think that makes it clear they don't want > to be a subset of the Lisp community?
Wow.
-- -> -/ - 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.
Bruce Hoult <br...@hoult.org> writes: > In article <87u1rixmm7....@photino.sid.rice.edu>, > Rahul Jain <rj...@sid-1129.sid.rice.edu> wrote: > > Bruce Hoult <br...@hoult.org> writes: > > > In article <87vgbyz9jo....@photino.sid.rice.edu>, > > > Rahul Jain <rj...@sid-1129.sid.rice.edu> wrote: > > > > I think that if scheme is a lisp, then it would be a very strange > > > > concept to call ML not a lisp. > > > Scheme and ML fail my "Can you easily transliterate textbook programs > > > from one language into the other language?" test. > > So the syntax is what matters? Java is a C, then? > No, syntax does not matter. For example, Common Lisp and Dylan can > usually be easily transliterated into each other, but the syntax is > quite different.
It all depends on what's "usual".
> > And what textbook are you talking about? I can't believe that there > > are textbooks which don't use call/cc > As someone just pointed out, SICP doesn't mention call/cc. I hadn't > realised that, but SICP is pretty much the clasic > textbook-that-uses-scheme.
So we should use a book that uses a language to teach general concepts as the standard textbook for that language? I don't get the point of this "textbook program" idea.
> > > ML examples make frequent use of implicit currying. > > That's syntactic sugar, really. > True, and you can emulate it in Scheme using lambdas and/or an explicit > "curry", but it's used heavily enough in ML to cause a lot of code > expansion when translated to Scheme.
Same with porting code that uses CLOS or conditions to Scheme. Or code that uses call/cc to Lisp.
> Perhaps a better example (which I mentioned yesterday but forgot today) > is the heavy use of pattern matching in ML.
That can be done without too much trouble with COND. As much trouble as any other differences between the languages.
> > > > > I'm a bit unclear about the "notation for functions in terms of > > > > > conses" requirement, also. > > > > [...] > > > I don't see why that is important for languages that don't have "eval" > > > or procedural macros, such as ML, Dylan, and (believe it or not) Scheme > > > until recently. > > Yes, exactly. :) > Well, if you think that "eval" is essential then list *it*, not the > incidental "notation for functions in terms of conses".
Perl has eval, too.
-- -> -/ - 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.
Erik Naggum <e...@naggum.net> wrote: > Such idiotic wars is not what technical newsgroups are for.
All of you would do the public image of comp.lang.lisp a great favour, if you would carry out those pointless arguments (not even discussions) consisting of accusations and counter-accusations with often unnecessarily harsh language in private.
