Lisp and Scheme.....
Chung-Lin Tang
answered that, but does one need to learn Lisp or Scheme
after experience with the other? Also, I'm new to FP, so
if I were to start with Lisp/Scheme, which should I learn(first)?
Thanks in advance.....
Janos Blazi
to Scheme. They have the same spirit and are very similar. But there are a
lot of minor differences. For example you define functions slightly
differently in both languages.
Scheme has been created for educational purposes. Some of its concepts may
be a bit cleaner (I'd prefer the term more simple) mut maybe a bit less
applicable.
Scheme is much smaller than Common Lisp.
So if you want to apply LISP, and you most likely want to, then take Common
Lisp. Common Lisp also has a powerful object system (CLOS) so if OOP suits
your way of thinking, CL is you choice number one.
If, on the other hande, you are an absolute beginner, you may be better off
with Scheme. There are some very nice introductory texts for Scheme, for
example "Simply Scheme" or "Concrete Abstract ion" (I like this one very
much!) or at a higher level SICP. Everybody here can give you the details if
you are interested.
Janos Blazi
Chung-Lin Tang <u883...@cc.nctu.edu.tw> schrieb in im Newsbeitrag:
38903702...@cc.nctu.edu.tw...
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
Bob Shafer
>
>If, on the other hande, you are an absolute beginner, you may be better off
>with Scheme. There are some very nice introductory texts for Scheme, for
>example "Simply Scheme" or "Concrete Abstract ion" (I like this one very
>much!) or at a higher level SICP. Everybody here can give you the details if
>you are interested.
On the other other hand, if you ultimately want to be doing CL, then I'd
skip Scheme. I didn't, and so now I often type "define" instead of "defun"
(although thankfully not so much anymore) and also, more often, I do
something like:
(defun (foo bar zap) ...)
instead of
(defun foo (bar zap) ...)
And those are just trivial examples of the fact that CL has a different
mind-set from Scheme. Looping style is a less trivial difference.
Which leads me to a question I've been meaning to ask. Erik, the other
day, mentioned something about 40 years of collective Lisp experience
vs. a newbie's first 3 years. Although I've messed around with Lisp for
years, I've only begun to get serious with Common Lisp lately, and find
myself perhaps only a month or two along in that first 3 years. One of
the things I find frustrating, being as I usually program into C or Java,
is that expressions are so long-winded. Opening a file for writing seems
to take forever, typing-wise.
How do people handle that? Formatting (my guess). Macros (bad idea?).
Here's an example: string concatenation. As far as I know, to concatenate
two strings, you'd do (concatenate 'string a b). I wrote a dead simple
macro, so I could do (strcat a b) instead. Is that bad form? I feel like
it is, and so I tend to avoid doing that these days. But what do other
people do?
Thanks,
-Newbie Bob
PS: I'm finally making some progress with CL due mainly to ANSI Common
Lisp, by Paul Graham. With the HyperSpec as backup, it provides examples
and discussions of things I really didn't know about enough to even be
looking for, let alone using, plus it has that reference section. I also
have On Lisp (had it for months before getting the CL book), but what
I needed was an overview of all that is available in CL, not a guide
to how to use it more cleverly. I'm sure On Lisp will be handy a bit
further down the road, however. Heck, maybe the kinds of questions I'm
asking above are dealt with in On Lisp.... He has that "while" macro that
seems just like the "strcat" kind of thing I discuss above, for instance.
Janos Blazi
was not clear enough.
As to you question: I am interested in getting an aswer too. I used to hard
code thing with macros, but somebody (I think Barry Mergolin (??) pointed
out that this was poor style. And --- he was right.
J.B.
Bob Shafer <bo...@localhost.localdomain> schrieb in im Newsbeitrag:
slrn890m2...@localhost.localdomain...
Lars Marius Garshol
* Bob Shafer
|
| PS: I'm finally making some progress with CL due mainly to ANSI
| Common Lisp, by Paul Graham. With the HyperSpec as backup, it
| provides examples and discussions of things I really didn't know
| about enough to even be looking for, let alone using, plus it has
| that reference section.
I found that very useful myself, but later I've found that I would
really have liked find coverage of topics like
- system building (compilation, #-/#+, defsystem, ...)
- packages
- conditions
and probably more that I can't remember right now. This isn't as much
criticism of Graham's book as it is a veiled plea for help. :-)
--Lars M.
Andrew Cooke
Chung-Lin Tang <u883...@cc.nctu.edu.tw> wrote:
> How much does Lisp and Scheme differ? I know the FAQ
> answered that, but does one need to learn Lisp or Scheme
> after experience with the other? Also, I'm new to FP, so
> if I were to start with Lisp/Scheme, which should I learn(first)?
Scheme is a *lot* simpler. It's simple enough for Abelson and Sussman
to cover it in a few chapters (and that book is a good reason to learn
Scheme, at least to the point where you can understand the rest of the
book).
Common Lisp is a much wider language. With Scheme you are constrained
to writing programs pretty much the way A&S describe, unless you start
writing your own extensions/libraries. In contrast, Common Lisp has
things like OO features "built in".
So I would suggest reading A&S (and learning some Scheme on the way)
for an intro to Lisp-like languages, but then switching to Common Lisp
for actually writing software.
If you do learn Lisp, I would recommend reading Graham's "On Lisp" as
early as possible. I think it's an excellent book - it pushes a way of
using the language that brings out some of Common Lisp's strengths (I
think). But first, get "Common Lisp the Language 2" and the hyperspec
(both available electronically) which are the standard references.
www.alu.org.
OTOH, Scheme seems to be more trendy at the moment...
Take all the above with a pinch of salt - I am a newbie here.
Andrew
http://www.andrewcooke.free-online.co.uk/index.html
Sent via Deja.com http://www.deja.com/
Before you buy.
Duane Rettig
> One of
> the things I find frustrating, being as I usually program into C or Java,
> is that expressions are so long-winded. Opening a file for writing seems
> to take forever, typing-wise.
>
> How do people handle that? Formatting (my guess). Macros (bad idea?).
Although I'm not familiar with the other editor interfaces, they should
do similar things as our Emacs-Lisp-Interface (eli); if for example you
type exactly `r-e-p-l' (without the quotes) and then type M-tab, it will
be replaced with excl::read-eval-print-loop. Of course, the more mundane
completions work as well, where you supply the first part and the
completion is given, or a choice of multiple completions. One of the
reasons to love an integrated emacs/lisp environment...
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Max Hailperin
...
> Here's an example: string concatenation. As far as I know, to concatenate
> two strings, you'd do (concatenate 'string a b). I wrote a dead simple
> macro, so I could do (strcat a b) instead. Is that bad form? I feel like
> it is, and so I tend to avoid doing that these days. But what do other
There are two basic approaches to typing less:
(1) Get the user interface of your programming environment -- your
text editor or structure editor or whatever it is -- to allow you
to press few keys to generate lots of code. One of the other
posters showed a specific example of this, but there are lots of
variations on the theme, whereby a couple keystrokes would
suffice to get "(concatenate 'string " into the program you are
editing.
(2) Get the macro facility of the programming language to expand a
short program into a longer one, so that you only need to enter
the short one -- this is what you show with strcat.
The reason why those of us who have hacked Lisp for decades seem to
have all wound up prefering option (1) in the end (at least, all the
ones I've worked with), even though option (2) seems conceptually
pretty cool, is that programs need to be read and not just written.
If you take option (2), the language pretty quickly fragments into
lots of local or even personal dialects, where to read anyone else's
code you need to first read and understand all their macro
definitions. On the other hand, you can read your own code at high
speed. So, you wind up with a disincentive to reading each others
code -- which is exactly the wrong thing to have happen for quality.
-max
Erik Naggum
| How much does Lisp and Scheme differ?
completely. two completely different cultures, two completely different
measures of success, two completely different concepts of elegance and
usability, two completely different sets of semantics for superficially
similar forms of expression. as languages, they have less in common than
Ada and Perl. as user communities, only the Scheme people believe that
they are using a Lisp, based on the belief that retaining parentheses and
prefix form is enough to remain a Lisp -- and, of course, the desire in
the Scheme community to convert people to their pure religion, a desire
you won't find in any other Lisp-derived community, especially not those
of the languages who have any purity to boast about. Scheme has the
world's most elegant, yet closed, language specification, while the other
Lisp family members focus on elegant language _use_ and _extension_.
while this may be taken as an exaggeration, it's less of an exaggeration
than the ignorant opinion that these languages are substantially the same.
Scheme is worth learning well -- no other language has a more succinct
way of teaching you programming language concepts, but the language also
has the most succinct way of teaching you language design mistakes if you
listen critically to its many design decision and don't accept them as
the gospel they are attempted sold as.
Common Lisp is worth knowing and using well -- no other language has a
more succinct (yet supremely readable) expression of complex, real-life
programming tasks and problems, and your ability to build your language
towards your problem is its most unique strength, yet the very concept of
building a language suitable to a problem is foreign to most other
languages and programming cultures.
incidentally, Scheme was a very good example of what happens when you
take a particular, favored programming methodology and hard-code it into
a language design -- you find that as you optimize your design too much,
you lose the freedom to do anything else with similar ease without having
to create _another_ and separate mini-language, and this means writing
all the support machinery all over again for every langauge -- a favored
academic exercise worth approximately nothing outside academia once you
get the degree.
#:Erik
Bob Shafer
Well said.
And thanks to you and everyone else for bringing up yet another concept
that I sort of knew about, but never knew was useful for proper
CL programming: abbreviations... I'd have never guessed.
Clearly, my next step in using CL is to get a proper lisp mode installed
(ilisp? -- I'm use clisp (on linux)). That's another thing I haven't
spent enough time with yet, using emacs and clisp together. I tend to
use them separately (save the file in emacs, then load it into clisp).
I know there's a better way, I just haven't taken the time to get into
it yet.
Michael Hudson
> Well said.
>
> And thanks to you and everyone else for bringing up yet another concept
> that I sort of knew about, but never knew was useful for proper
> CL programming: abbreviations... I'd have never guessed.
>
> Clearly, my next step in using CL is to get a proper lisp mode installed
> (ilisp? -- I'm use clisp (on linux)). That's another thing I haven't
> spent enough time with yet, using emacs and clisp together. I tend to
> use them separately (save the file in emacs, then load it into clisp).
> I know there's a better way, I just haven't taken the time to get into
> it yet.
Take the time. It's sooo much better than the alternative (and clisp's
actually quite nice on the command line).
It's probably worth making sure you have the latest versions of both
packages.
Cheers,
Michael
Robert Monfera
Andrew Cooke wrote:
> Scheme is a *lot* simpler.
Of course, as it is smaller. On the other hand, the success of learning
a language should not be measured in terms of what percentage of the
standard functions can be learned a day, but instead what functionality
or development efficiency you can achieve. I have a lot of fun
_knowing_ that the functions I need will be there, even if I do not know
their name. It's also a pleasure to think hard about problems, browse
the Hyperspec and then semi-accidentally discover that sometime, someone
with a lot of experience went through this and a better solution
crystallized over time than I thought was possible.
> So I would suggest reading A&S (and learning some Scheme on the way)
> for an intro to Lisp-like languages, but then switching to Common Lisp
> for actually writing software.
Switching languages has its costs, and unless someone is interested
specifically in what Scheme emphasizes, it may be more practical to
start with CL right away.
> If you do learn Lisp, I would recommend reading Graham's "On Lisp" as
> early as possible. I think it's an excellent book [...]
Yes, it is, but it's a more advanced book than introductory texts like
ANSI Common Lisp also from Graham. On Lisp admittedly gives a
substantial sampling on CL's strengths, but ANSI CL does a fair job
too. David Lamkins' Successful Lisp is a very good on-line write-up on
many of CL's features.
> But first, get "Common Lisp the Language 2" and the hyperspec
> (both available electronically) which are the standard references.
> www.alu.org.
As a rule of thumb, I'd suggest the Hyperspec in the first place, and
turn to CLtL2 for historical insight or parts that didn't make it into
the standard (like Series).
Regards
Robert
Paolo Amoroso
wrote:
> is that expressions are so long-winded. Opening a file for writing seems
> to take forever, typing-wise.
ILISP's symbol completion can save you from RSI (Repetitive Symbol Injury
:-) ILISP is an Emacs interface for interacting with Lisp processes. It's
available at:
I guess other Lisp environments provide similar features.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
arthurg...@my-deja.com
Erik Naggum <er...@naggum.no> wrote:
> * Chung-Lin Tang <u883...@cc.nctu.edu.tw>
> | How much does Lisp and Scheme differ?
>
> completely. two completely different cultures, two completely
> different measures of success, two completely different concepts
> of elegance and usability, two completely different sets of
> semantics for superficially similar forms of expression.
Agreed.
> as languages, they have less in
> common than Ada and Perl.
This is too extreme an analogy. Of course, Common Lisp does have a
lot in common with Perl. (Sorry. I couldn't help myself.)
> as user communities, only the Scheme people believe
> that they are using a Lisp, based on the belief that retaining
> parentheses and prefix form is enough to remain a Lisp -- and, of
> course, the desire in the Scheme community to convert people to
> their pure religion, a desire you won't find in any other
> Lisp-derived community, especially not those of the languages who
> have any purity to boast about.
I don't believe that "only the Scheme people believe that they are
using a Lisp." That certainly hasn't been my experience when talking
with Common Lisp users. But perhaps they were being polite.
The strongest argument I can make that Scheme is not a Lisp is that
standard Scheme doesn't have a powerful macro system. Except in the
most trivial sense, it is not possible to use R5RS macros to write
programs that write programs. Specifically, the pattern-matching
system in R5RS macros does not allow one to run code (i.e. procedures)
at macro-expansion time that decides what the resulting expansion
should be. You could certainly argue that standard Scheme doesn't
have macros at all in the sense that Common Lisp and other Lisps do,
and that's a shame. Of course, most Scheme implementations have real,
Lisp-style macros, but they aren't standard and therefore aren't
portable.
However, this failing alone is not enough to put Scheme in a
completely different family of languages than Lisp.
> Scheme has
> the world's most elegant, yet closed, language specification,
> while the other Lisp family members focus on elegant language
> _use_ and _extension_.
>
> while this may be taken as an exaggeration, it's less of an
> exaggeration than the ignorant opinion that these languages are
> substantially the same.
We should be able to discuss this issue without the use of ad hominem
phrases like "only the Scheme people believe," "the desire in the
Scheme community to convert people to their pure religion," and
"ignorant opinion" -- even if those phrases are accurate.
> Scheme is worth learning well -- no other language has a more
> succinct way of teaching you programming language concepts, but
> the language also has the most succinct way of teaching you
> language design mistakes if you listen critically to its many
> design decision and don't accept them as the gospel they are
> attempted sold as.
Since you posted your message in <comp.lang.scheme>, would you give
specific examples of what you mean by this? Since there is so much
language design activity still going on in the Scheme world, it would
be nice to see where Scheme could be improved.
> Common Lisp is worth knowing and using well -- no other language
> has a more succinct (yet supremely readable) expression of
> complex, real-life programming tasks and problems, and your
> ability to build your language towards your problem is its most
> unique strength, yet the very concept of building a language
> suitable to a problem is foreign to most other languages and
> programming cultures.
It is true that Common Lisp is wonderful. Standard Common Lisp has
many advantages over standard Scheme, including a large,
well-thought-out set of data structures and libraries, a powerful
macro system, and a powerful system for object-oriented programming.
> incidentally, Scheme was a very good example of what happens when
> you take a particular, favored programming methodology and
> hard-code it into a language design -- you find that as you
> optimize your design too much, you lose the freedom to do anything
> else with similar ease without having to create _another_ and
> separate mini-language, and this means writing all the support
> machinery all over again for every langauge -- a favored academic
> exercise worth approximately nothing outside academia once you get
> the degree.
What do you mean by this, specifically?
I've enjoyed your posts in <comp.lang.lisp> for a long time, but I've
never understood your claim that Scheme is not a Lisp. You've made
many good arguments in favor of Common Lisp, but I just don't
understand the "Scheme is not a Lisp" position.
I've programmed in Lisp (including Scheme) for years, and I'm often on
the fence when it comes to whether to use Common Lisp or Scheme for
personal projects. Perhaps you could help me make up my mind.
arthurg...@my-deja.com
Ray Blaak
>
> > One of
> > the things I find frustrating, being as I usually program into C or Java,
> > to take forever, typing-wise.
> >
Structure your abstractions properly. This is a rule that works for any
language.
If the basic services available to you are too tedious, find or make some
wrapper classes that present the services in a more natural, readable, and
succinct way.
E.g.
File file("/a/b/c/myfile.txt");
if (file.Exists()) {...}
file.Open(); // exception on error, so no need to check for return codes.
String s = file.ReadLine();
file.Close();
Or just:
FileIterator file("/tmp/whatever.dat");
FileVisitor v;
file.Traverse(v); // calls v.Visit(line) on each line of the file
etc.
Be creative. (Apologies for not showing this as Lisp.)
Fancy auto-completion in editors might be fine for the writer -- once. The
real fix is to make the code more expressive and conceptually simpler. Then it
is also easier to fix it later, as opposed to just writing it the first time.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
bl...@infomatch.com The Rhythm has my soul.
Gareth McCaughan
> One of
> the things I find frustrating, being as I usually program into C or Java,
> is that expressions are so long-winded. Opening a file for writing seems
> to take forever, typing-wise.
That's an illusion.
(with-open-file (f "foo.txt" :direction :output)
)
51 bytes
FILE * f = fopen("foo.txt", "w");
fclose(f);
45 bytes
FileWriter f = new FileWriter("foo.txt");
f.close();
53 bytes
And the Lisp version sticks f in a local scope, and closes the
file for you if a non-local exit from that block happens. Adding
a level of scope will add another 4 bytes to the C and Java
versions. Dealing with non-local exits in C ... hmmmmm. In
Java, you need to add a try/finally block.
It's true that the Lisp *seems* verbose. But in looking
at that nasty long function name, you're missing the absence
of pointless syntactic nastiness, explicit type declarations,
and code to do the Right Thing instead of the Easiest Thing.
As has been pointed out, if you find typing WITH-OPEN-FILE
too arduous then a good text editor or development environment
(or, in the case of emacs, both at once) can save lots of
the typing.
--
Gareth McCaughan Gareth.M...@pobox.com
sig under construction
Erik Naggum
| Since you posted your message in <comp.lang.scheme>, ...
I apologize. that was a mistake. cross-posting is evil, and between
Scheme and Lisp communities even more so. I have told my newsreader to
flag such articles when responding to them. I'll have a stern talk with
it as to why it failed to alarm me this time. bad software! bad!
#:Erik
Andrew Cooke
learning
> a language should not be measured in terms of what percentage of the
> standard functions can be learned a day, but instead what
functionality
> or development efficiency you can achieve.
I wasn't recommending he learnt Scheme because it was simple, but
because it is used in Abelson + Sussman's book. I'm not saying become
an expert - you don't need to be an expert in Scheme to understand that
book. But the book is worth (IMHO) it.
[...]
> > If you do learn Lisp, I would recommend reading Graham's "On Lisp"
as
> > early as possible. I think it's an excellent book [...]
> Yes, it is, but it's a more advanced book than introductory texts like
> ANSI Common Lisp also from Graham. On Lisp admittedly gives a
> substantial sampling on CL's strengths, but ANSI CL does a fair job
> too. David Lamkins' Successful Lisp is a very good on-line write-up
on
> many of CL's features.
As I haven't read the books I can't argue here - I just want to explain
why I recommend On Lisp at an early age.
First: I read Norvig's book before using Lisp, then used CLtL2 and the
hyperspec (and this group) to start programming. But Norvig seems to be
uncomfortable with macros ("Introducing a macro puts much more strain on
the reader of your program") and sections of On Lisp seem to argue
directly with that view (can't find the quote I'm looking for - sorry).
Whatever you feel, you can't make up your own mind til you've read both
sides.
Second: I'm assuming that the person who first asked can already
program. Most introductory texts spend a fair amount of time teaching
you basics that are either pretty obvious after learning a few
languages, or can be gleaned from the references (the big plus to A&S is
that it makes even the introductory material interesting and stretches
to some quite advanced ideas). In contrast, the first few chapters of
On Lisp introduce the language and make the case for macros. The later
chapters can be left til later.
I guess it comes down to personal preferences - I like books that
introduce new ideas so fast I struggle to keep up, rather than books
that make my progress sure but slow. I'd rather stumble but see where
I'm going than be safe but without the view (of course someone who felt
differently would phrase that so that the alternative was more
attractive!).
> > But first, get "Common Lisp the Language 2" and the hyperspec
> > (both available electronically) which are the standard references.
> > www.alu.org.
> As a rule of thumb, I'd suggest the Hyperspec in the first place, and
> turn to CLtL2 for historical insight or parts that didn't make it into
> the standard (like Series).
I had problems finding a copy of the hyperspec that would download onto
my NT "work" machine I have connected to the net and then copy across to
my Linux "pleasure" box. In the end I found a copy on a freebie Allegro
CD, but I spent a fair amount of time with CLtL2. Maybe because of that
(and because I don't have an "introductory" book) I prefer CLtL2 - it
seems to have more descriptive material (and a sense of humour).
Andrew
P.S. I've just noticed this is going to both the Scheme group and the
Lisp group - I'm surprised that the reponses are so uniform!
David Rush
c.l.s lately but since only c.l.l people seem to be responding...
Chung-Lin Tang <u883...@cc.nctu.edu.tw> writes:
> How much does Lisp and Scheme differ? I know the FAQ
> answered that, but does one need to learn Lisp or Scheme
> after experience with the other? Also, I'm new to FP, so
> if I were to start with Lisp/Scheme, which should I learn(first)?
I swear that this sounds like a troll...
Which do you prefer C or C++? Do you prefer designing and coding
programs or do you enjoy deciphering puzzles and finding new features
to exploit? Would you rather drive a Porsche 911 or a Rolls Royce
Silver Ghost?
Scheme is small and very bare-metal in its feel. One of the best
(most aggressively optimizing) compilers on the planet (Stalin) was
built for Scheme. It's also way cleaner. Seat belts are optional. So
is a CD player, but you can get it from somewhere if you think its not
worth the effort to build your own.
CL, OTOH, is huge, but *everything* is included. This is a plus in
certain kinds of development, but it can also mean that you build
things without a proper understanding of the costs. There are good CL
compilers.
For me, the gripping hand holds the theoretical clarity and
completeness of Scheme in preference to the bells and whistles of
CL. I like to be able to look at my code and *know* it's correct
without having to refer to 4 different places in the language/library
spec. And the Stalin compiler is a big incentive when you've got a
world which believes that truly high-level languages are inherently
inefficient...
YMMV,
david rush
--
If you give someone Fortran, he has Fortran.
If you give someone Lisp, he has any language he pleases.
-- Guy L. Steele Jr.
David Rush
> * Chung-Lin Tang <u883...@cc.nctu.edu.tw>
> | How much does Lisp and Scheme differ?
> measures of success, two completely different concepts of elegance and
> usability, two completely different sets of semantics for superficially
> similar forms of expression.
Perhaps somewhat overstated, but substantially correct.
> as user communities, only the Scheme people believe that
> they are using a Lisp, based on the belief that retaining parentheses and
> prefix form is enough to remain a Lisp
Well *I* alway thought that LISP stood for Lots of Irritating Silly
Parentheses. Oh yeah, that's right it used to mean LISt Processing
language. Hmmm. Well the primary data structure in Scheme is still the
list (well, trees of cons-cells interpreted as lists, but that's
theoretical purity for you). I guess that Scheme is a lisp on both of
those counts...
> -- and, of course, the desire in
> the Scheme community to convert people to their pure religion,
Which desire is *clearly* absent from your soul.
> Scheme has the
> world's most elegant, yet closed, language specification, while the other
> Lisp family members focus on elegant language _use_ and
> _extension_.
Actually, I would say that Scheme leaves the notion of language
extension to the user, avoiding the arrogance that only the language
designer is clever enough to do such things.
> Scheme is worth learning well -- no other language has a more succinct
> way of teaching you programming language concepts, but the language also
> has the most succinct way of teaching you language design mistakes if you
> listen critically to its many design decision and don't accept them as
> the gospel they are attempted sold as.
Such as? I think that there is probably only one actual *bad idea* in
the language spec, but it's not really clear how to properly fix
it. The only other problem with the language is merley an annoyance.
> Common Lisp is worth knowing and using well -- no other language has a
> more succinct (yet supremely readable) expression of complex, real-life
> programming tasks and problems,
Smalltalk. (but I'm sure not going to cross-post this message over *there*)
> and your ability to build your language
> towards your problem is its most unique strength, yet the very concept of
> building a language suitable to a problem is foreign to most other
> languages and programming cultures.
Not to the Scheme world. I would say that the language positively
encourages it by providing only fundamental tools.
> incidentally, Scheme was a very good example of what happens when you
> take a particular, favored programming methodology and hard-code it into
> a language design -- you find that as you optimize your design too much,
> you lose the freedom to do anything else with similar ease without having
> to create _another_ and separate mini-language, and this means writing
> all the support machinery all over again for every langauge -- a favored
> academic exercise worth approximately nothing outside academia once you
> get the degree.
I am not an academic. I *really* like Scheme.
david rush
--
If you give someone Fortran, he has Fortran.
If you give someone Lisp, he has any language he pleases.
-- Guy L. Steele Jr. (who gave us both CL & Scheme)
Marco Antoniotti
arthurg...@my-deja.com writes:
> The strongest argument I can make that Scheme is not a Lisp is that
> standard Scheme doesn't have a powerful macro system.
DEFSTRUCT anybody? Multi-dimensional arrays?
> Since you posted your message in <comp.lang.scheme>, would you give
> specific examples of what you mean by this? Since there is so much
> language design activity still going on in the Scheme world, it would
> be nice to see where Scheme could be improved.
The only design effort that is needed in Scheme is to get the ANSI CL
standard stick in Scheme everything that is missing (since 1984). But
then you'd have Common Lisp :)
> It is true that Common Lisp is wonderful. Standard Common Lisp has
> many advantages over standard Scheme, including a large,
> well-thought-out set of data structures and libraries, a powerful
> macro system, and a powerful system for object-oriented programming.
Exactly. :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
Andrew Cooke
David Rush <ku...@bellsouth.net> wrote:
> Actually, I would say that Scheme leaves the notion of language
> extension to the user, avoiding the arrogance that only the language
> designer is clever enough to do such things.
This are probably old points - I'm a newish Lisp user.
- Surely defmacro lets the user extend Common Lisp?
- Extensions like CLOS are pretty impressive. I wouldn't like to have
to write all that before I could use its functionality.
- If I did want to extend Common Lisp, what makes that more difficult
than Scheme? Does Scheme have something Common Lisp does not?
- Common Lisp wasn't designed by a single "designer", but is the
collected wisdom of a lot of years of experience.
Basically, I don't think I understand you point! You can expand Lisp as
much as Scheme, there's no arrogant designer, and you don't have to
reinvent the wheel (especially when the wheel is something as impressive
and complex as CLOS).
Andrew
Frank A. Adrian
David Rush <ku...@bellsouth.net> wrote in message
news:okfwvou...@bellsouth.net...
> Erik Naggum <er...@naggum.no> writes:
> > Common Lisp is worth knowing and using well -- no other language has a
> > more succinct (yet supremely readable) expression of complex,
real-life
> > programming tasks and problems,
>
> Smalltalk. (but I'm sure not going to cross-post this message over
*there*)
Not quite. To do anything as useful as with Lisp macros in Smalltalk, your
code generation methods becomes quite clunky. I've done it. Too much
syntax. Similarly, the double dispatch hack is no substitute for
multimethods. And let's not forget that up to about five years ago, you
were never sure whether a Smalltalk was going to have lexically closed
variables or not. Thankfully, they fixed that one in the ANSI standard (but
I'm still not going to post it over there, either).
faa
Marco Antoniotti
Andrew Cooke <and...@andrewcooke.free-online.co.uk> writes:
> In article <okfwvou...@bellsouth.net>,
> David Rush <ku...@bellsouth.net> wrote:
> > Actually, I would say that Scheme leaves the notion of language
> > extension to the user, avoiding the arrogance that only the language
> > designer is clever enough to do such things.
Why isn't this true of Common Lisp as well?
> This are probably old points - I'm a newish Lisp user.
>
> - Surely defmacro lets the user extend Common Lisp?
>
> - Extensions like CLOS are pretty impressive. I wouldn't like to have
> to write all that before I could use its functionality.
CLOS used to be an extension. It is not anymore in Common Lisp.
> - If I did want to extend Common Lisp, what makes that more difficult
> than Scheme? Does Scheme have something Common Lisp does not?
Yes: a lack of so many features that you need to extend the language
to make it useful. Hence ending up with a subset of the features in
Common Lisp.
> - Common Lisp wasn't designed by a single "designer", but is the
> collected wisdom of a lot of years of experience.
>
> Basically, I don't think I understand you point! You can expand Lisp as
> much as Scheme,
This is incorrect. Common Lisp cannot be expanded as much as Scheme
since it already contains all the features you need to write
interesting programs.
> there's no arrogant designer, and you don't have to
> reinvent the wheel (especially when the wheel is something as impressive
> and complex as CLOS).
Exactly.
(make-array 1000 :element-type 'string :initial-element ":)")
Erik Naggum
| > -- and, of course, the desire in
| > the Scheme community to convert people to their pure religion,
|
| Which desire is *clearly* absent from your soul.
geez. rejecting religion is not a belief, despite attitudes prevalent in
certain religious circles. matter of fact, I don't want to convert
anyone (except to metric and ISO 8601) -- in my admittedly arrogant view,
if you need conversion, you're already a waste of space and time.
#:Erik
Bruce Hoult
<ku...@bellsouth.net> wrote:
> Scheme is small and very bare-metal in its feel. One of the best
> (most aggressively optimizing) compilers on the planet (Stalin) was
> built for Scheme.
Is Stalin good enough that it's worth using it instead of C as a target
for compilers for other languages? Even object-oriented ones, generating
closures to represent objects?
-- Bruce
Vebjorn Ljosa
> I had problems finding a copy of the hyperspec that would download onto
> my NT "work" machine I have connected to the net and then copy across to
> my Linux "pleasure" box. In the end I found a copy on a freebie Allegro
> CD, but I spent a fair amount of time with CLtL2. Maybe because of that
> (and because I don't have an "introductory" book) I prefer CLtL2 - it
> seems to have more descriptive material (and a sense of humour).
I guess you found it at last, but in case someone else is still
looking for the Hyperspec tarball:
<URL:http://www.harlequin.com/support/books/HyperSpec/HyperSpec-4-0.tar.gz>
--
Vebjorn Ljosa
Rob Warnock
+---------------
| I don't want to convert anyone (except to metric and ISO 8601)
Ditto, to both.
-Rob
p.s. Anyone who hasn't read Erik's delightful polemic "The Long,
Painful History of Time" <URL:http://www.naggum.no/lugm-time.html>
really, really should.
-----
Rob Warnock, 8L-846 rp...@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
Marco Antoniotti
arthurg...@my-deja.com writes:
> In article <31579785...@naggum.no>,
> Erik Naggum <er...@naggum.no> wrote:
> > * Chung-Lin Tang <u883...@cc.nctu.edu.tw>
> > | How much does Lisp and Scheme differ?
> >
> > completely. two completely different cultures, two completely
> > different measures of success, two completely different concepts
> > of elegance and usability, two completely different sets of
> > semantics for superficially similar forms of expression.
>
> Agreed.
>
> > as languages, they have less in
> > common than Ada and Perl.
>
> This is too extreme an analogy. Of course, Common Lisp does have a
> lot in common with Perl. (Sorry. I couldn't help myself.)
Well, you should have! :) It is well known that all languages have
something in common with Common Lisp. Not the other way around. Apart
from type inference it is a many-to-one relationship :)
Marco Antoniotti
NOISE AHEAD!
Marco Antoniotti <mar...@parades.rm.cnr.it> writes:
> arthurg...@my-deja.com writes:
> > This is too extreme an analogy. Of course, Common Lisp does have a
> > lot in common with Perl. (Sorry. I couldn't help myself.)
>
> Well, you should have! :) It is well known that all languages have
> something in common with Common Lisp. Not the other way around. Apart
> from type inference it is a many-to-one relationship :)
I should correct myself. :)
INTERCAL is an obvious exception to the above rule. :)
Cheers
Janos Blazi
"LISP is the father of all things". It is well known thet the US army uses
ADA. This is why the hit the Chinese ambassy though they admittedly did not
want to. Haf the used LISP (or Scheme that is almost the sam) insetad, this
could not have happened of course.
Apropos Scheme: When Moses cam back from the Mountain where he spoke with
God, he forgot one of the commanmends: Thou shalt have no other LISP, only
CL. (Sorry, my English ist not good enough for that...)
Janos Blazi
Marco Antoniotti <mar...@parades.rm.cnr.it> schrieb in im Newsbeitrag:
lw66wdk...@parades.rm.cnr.it...
>
> arthurg...@my-deja.com writes:
>
> > In article <31579785...@naggum.no>,
> > Erik Naggum <er...@naggum.no> wrote:
> > > * Chung-Lin Tang <u883...@cc.nctu.edu.tw>
> > > | How much does Lisp and Scheme differ?
> > >
> > > completely. two completely different cultures, two completely
> > > different measures of success, two completely different concepts
> > > of elegance and usability, two completely different sets of
> > > semantics for superficially similar forms of expression.
> >
> > Agreed.
> >
> > > as languages, they have less in
> > > common than Ada and Perl.
> >
> > This is too extreme an analogy. Of course, Common Lisp does have a
> > lot in common with Perl. (Sorry. I couldn't help myself.)
>
> Well, you should have! :) It is well known that all languages have
> something in common with Common Lisp. Not the other way around. Apart
> from type inference it is a many-to-one relationship :)
>
>
>
> --
> Marco Antoniotti ===========================================
> PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
> tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
> http://www.parades.rm.cnr.it/~marcoxa
-----------== Posted via Newsfeeds.Com, Uncensored Usenet News ==----------
http://www.newsfeeds.com The Largest Usenet Servers in the World!
------== Over 73,000 Newsgroups - Including Dedicated Binaries Servers ==-----
Jeff Dalton
Scheme is a subfamily of Lisp.
Here are some reasons to say Scheme is a subcatgory of Lisp:
* History.
* Established usage of the terms "Scheme" and "Lisp".
* Intentions of language designers.
* Similarities between Schemes and other Lisps.
* That the differences are not greater than "Lisp" has accomodated
in the past.
* Politics.
Scheme does differ from other Lisps in certain ways, but there's
substantially more overlap than there used to be, and a number of
people have designed and implemented languages named "Lisp" that
were essentially Schemes rather than being more like older Lisps.
(Oaklisp, for instance.)
For a long time, there was often talk of "dialects of Lisp", as if
Lisp were a language rather than a language family. Probably there
still is such talk. There's not really much difference between the
two views, but there is a political aspect. Consider the line, though
I forget who said it, that a language is a dialect with an army. The
difference is chiefly political, we might say.
In any case, it became clear around the time Common Lisp was being
standardized that "dialect" talk was politicaly unwise, because it
made it sound like there ought to be one standard for all of Lisp.
A "traditional" point in the Lisp community had been that Lisps,
though they were all considered Lisp, differed as much things in the
Algol family that were regarded as separate languages. This was in
part thought to be a cool thing about Lisp (the "Lisp us a ball of
mud and a good thing too" argument) and in part thought to show how
misleading perceptions could be.
But suddenly we found this traditional point about Lisp's diversity
counting for less than mistaken perceptions based on nothing more than
the talk of "dialects" and a desire for the "one standard" view to
prevail.
That Scheme was a subcategory of Lisp was a useful weapon in those
battles, because it was fairly obvious that it would not do to have
only one standard.
The subcategory point is also a useful weapon at other times. The
idea that Scheme is not Lisp has often been used by people attacking
Common Lisp or "Lisp". In fact, in my experience the most common use
of "Scheme is not Lisp" is when making some ill-founded attack on
"Lisp" (typically something that's actually true of at most some kinds
of Lisp or of some implementations) and then rejecting any
Scheme-based counterexamples.
- jd