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 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 <u8832...@cc.nctu.edu.tw> schrieb in im Newsbeitrag:
38903702.A236D...@cc.nctu.edu.tw...

     (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

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:
slrn890m2k.m7.bo...@localhost.localdomain...

* 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. :-)

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

 (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.

  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.

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.

It's probably worth making sure you have the latest versions of both
packages.

  http://ilisp.cons.org/

I guess other Lisp environments provide similar features.

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.

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.

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.

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.

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.

    (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.

  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!

[...]

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!).

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!

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...

Cheers

- 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

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).

(make-array 1000 :element-type 'string :initial-element ":)")

Cheers