Common Lisp for Schemers
Brian Campbell
experienced in scheme? I would be especially interested in introductions
to CLOS, and also any gotchas in moving from scheme to Common Lisp (like
the defun/define distinction).
--
Brian Campbell
Real email: lambda (at) cs (dot) dartmouth (dot) edu
Dr. Edmund Weitz
> Are there any good introductions to Common Lisp for people who are
> experienced in scheme? I would be especially interested in
> introductions to CLOS, and also any gotchas in moving from scheme to
> Common Lisp (like the defun/define distinction).
I don't know of any such introductions but if there are any I'd like
to know (because I hope we might be able to include them into the
cookbook).
Apart from that there's Dorai Sitaram's 'scm2cl' (at
<http://www.cs.rice.edu/~dorai/scm2cl/scm2cl.html>) which converts
Scheme to Common Lisp. Maybe playing around with this tool and
studying its output will help you.
Good luck,
Edi.
--
Dr. Edmund Weitz
Hamburg
Germany
The Common Lisp Cookbook
<http://agharta.de/cookbook/>
Christopher C. Stacy
Brian> Are there any good introductions to Common Lisp for people who are
Brian> experienced in scheme? I would be especially interested in introductions
Brian> to CLOS, and also any gotchas in moving from scheme to Common Lisp (like
Brian> the defun/define distinction).
They are two pretty different languages, much more different than what
would appear to be syntax or spelling differences like define/defun.
(For example, those two forms don't really do the same thing at all!)
Vebjorn Ljosa
| Are there any good introductions to Common Lisp for people who are
| experienced in scheme? I would be especially interested in introductions
| to CLOS, and also any gotchas in moving from scheme to Common Lisp (like
| the defun/define distinction).
As introduction to CLOS, I would recommend Sonya E. Keene's
"Object-Oriented Programming in Common Lisp."
--
Vebjorn Ljosa
Erik Naggum
| Are there any good introductions to Common Lisp for people who are
| experienced in scheme? I would be especially interested in introductions
| to CLOS, and also any gotchas in moving from scheme to Common Lisp (like
| the defun/define distinction).
There is only one gotcha: Thinking that being experienced in Scheme helps
when you want to learn Common Lisp. It does not. In fact, much evidence
(i.e., past students) seems to indicate that it prevents you from
learning Common Lisp. So to learn Common Lisp if you know Scheme, keep
reminding yourself that any "Scheme ways" you think are similar are not.
When you think you "get" Common Lisp, you may compare them, but at this
point, it should be pointless. If you think in Scheme and write Common
Lisp, you will never learn Common Lisp. Therefore, return to the state
of mind of the novice before you embark on your journey.
///
--
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.
Ola Rinta-Koski
> There is only one gotcha: Thinking that being experienced in Scheme helps
> when you want to learn Common Lisp. It does not.
The opposite, however, is true. Or at least was true enough for me
to pass the one required Scheme course I had.
--
Ola Rinta-Koski o...@cyberell.com
Cyberell Oy +358 41 467 2502
Rauhankatu 8 C, FIN-00170 Helsinki, FINLAND www.cyberell.com
Marco Antoniotti
Brian Campbell <lambd...@yahoo.com> writes:
> Are there any good introductions to Common Lisp for people who are
> experienced in scheme? I would be especially interested in introductions
> to CLOS, and also any gotchas in moving from scheme to Common Lisp (like
> the defun/define distinction).
I suggest this goes in the Cookbook.
IMHO the key issues are:
1 - Named LET's (easily substituted by a macro).
2 - Nested `define's.
3 - You do not need call/cc 98% of the time.
4 - You do not need to rewrite the core libraries. :)
5 - The use of all those useful keywords.
The introduction to CLOS is another thing altogether.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Daniel Barlow
> 5 - The use of all those useful keywords.
And not just the keywords, either. All those useful argument list
options - &rest, &allow-other-keys, etc. Beats (define (foo . args) ...)
and having to pick the list apart by hand
And of course destructuring-bind for when you do want to pick the list
apart by hand.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Eric Moss
>
> Are there any good introductions to Common Lisp for people who are
> experienced in scheme? I would be especially interested in introductions
> to CLOS, and also any gotchas in moving from scheme to Common Lisp (like
> the defun/define distinction).
Assuming Erik's position on Scheme vis-a-vis Common Lisp, I recommend
"Common Lisp: an Interactive Approach" by Stuart Shapiro. Anyone who
*knows* CL says it's boring, but that's because they *KNOW* CL already,
so what do they know about it? ;) Experienced people gravitate toward
good *references*, which are rarely good tutorials, IMO.
The reason I like this book is that, similar to the Little Schemer, it
shows a LOT of variations on a single function, exploring all the
"gotchas" that other books mention via prose. Unless you read and
retain subtleties *very* well, it's easy to miss many of the truths in
CLTL2, for example, which require combining knowledge gleaned from many
different chapters.
In other words, Shapiro's book drags you through all the questions you
might not even know to ask until your code mysteriously doesn't work.
Unfortunately it's practically impossible to find.
Eric
Fernando Rodríguez
>IMHO the key issues are:
>
> 1 - Named LET's (easily substituted by a macro).
> 2 - Nested `define's.
> 3 - You do not need call/cc 98% of the time.
> 4 - You do not need to rewrite the core libraries. :)
> 5 - The use of all those useful keywords.
6 - Iteration is not heretic.
It could be useful to give a CL version of the "Laws & Commandments" in The
Little Schemer and The Seasoned Schemer".
----
Fernando Rodríguez
frr at wanadoo dot es
-------
Brian Campbell
Marco Antoniotti <mar...@cs.nyu.edu> wrote:
> Brian Campbell <lambd...@yahoo.com> writes:
>
> > Are there any good introductions to Common Lisp for people who are
> > experienced in scheme? I would be especially interested in introductions
> > to CLOS, and also any gotchas in moving from scheme to Common Lisp (like
> > the defun/define distinction).
>
> I suggest this goes in the Cookbook.
What is the Cookbook?
>
> IMHO the key issues are:
>
> 1 - Named LET's (easily substituted by a macro).
This was the second major difference I noticed, and writing a macro to
fix it was my first reflex.
> 2 - Nested `define's.
This was the first. (well, of course there's also the distinction
between functions and regular values, but that's not really a gotcha,
just a
> 3 - You do not need call/cc 98% of the time.
I have never actually used call/cc in any real code I've written in
scheme, but then again, I've never written the kind of thing that would
use it. For that other 2% of the time, though, it's damn handy. This
also ties into number 4; it's pretty useful for writing things like
conditions which common lisp already has.
By the way, are there any common lisps which have it? Or does it violate
anything in the common lisp standard? It would be pretty handy for
writing logical reasoning code with backtracking.
> 4 - You do not need to rewrite the core libraries. :)
This is why I am trying to learn common lisp. There's too much
reinventing of the wheel in scheme.
> 5 - The use of all those useful keywords.
Yep, those seem pretty useful.
How about the loop macro? I know there's a large amount of debate on it,
but I'm wondering what the people who are for it have to say about it,
since coming from scheme, I would just use tail-recursion. By the way,
does common lisp require tail-call optimization the way that scheme
does? Or is it supported by most implementations? Or will depending on
it cause me to waste gobs of memory, and I should use an itereation
construct instead?
In the day or two I've been seriously looking at common lisp, I've found
that the general style is the same, but without the minimalism that
seems to show up in scheme. For instance, I had just written a basic
memoization function which took a function and returned a memoized
version of it. While looking at a page of useful common lisp tricks, I
found a common lisp version, but with all kinds of features to save the
hash table to disk, unmemoize the function, etc. It was pretty similar
in feel, but it just had way more features.
>
> The introduction to CLOS is another thing altogether.
>
> Cheers
--
Kenny Tilton
Brian Campbell wrote:
>
> What is the Cookbook?
--
The Common Lisp Cookbook
<http://agharta.de/cookbook/>
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"We have a pond and a pool. The pond would be good for you."
- Ty to Carl, Caddy Shack
Thomas F. Burdick
> How about the loop macro? I know there's a large amount of debate on it,
> but I'm wondering what the people who are for it have to say about it,
> since coming from scheme, I would just use tail-recursion.
When you're iterating, it's usually more obvious to write the code in
an iterative form, not a recursive one. LOOP is nice because it
easily and clearly expresses a very large subset of the iterations
people write. We all *can* read tail-recursive functions -- it's
wanting to that's another story.
> By the way, does common lisp require tail-call optimization the way
> that scheme does?
No, it makes no guarantees about tail-call elimination.
> Or is it supported by most implementations?
I think most implementations support *some* form of tail-call
elimination at some optimization setting. The only time I rely on it
is when writing a set of mutually-recursive functions and I know that
I only care if the code works on CMUCL. If I wanted to port the code,
I'd probably wrap it up in some macrology. This type of stuff doesn't
come up very often, and is probably a style issue. I try to write in
the style that's easiest for me to read, although it's probably not
the best CL style to do this (for potentially-unbounded recursion,
that is -- for bounded recursion that I can assume will fit in the
stack, no problem).
> Or will depending on it cause me to waste gobs of memory, and I
> should use an itereation construct instead?
Yes.
> In the day or two I've been seriously looking at common lisp, I've found
> that the general style is the same, but without the minimalism that
> seems to show up in scheme.
I found that to be true at first. The more I dug into CL, the more I
found it differs. I'd say that if you want to learn CL, ignore the
similarities to Scheme. Certainly you've learned things from Scheme
that will be applicable to CL -- just as you may have from C or Java
or Smalltalk -- but they are different enough, that you should not
read too much into the similarities.
> For instance, I had just written a basic memoization function which
> took a function and returned a memoized version of it. While looking
> at a page of useful common lisp tricks, I found a common lisp
> version, but with all kinds of features to save the hash table to
> disk, unmemoize the function, etc. It was pretty similar in feel,
> but it just had way more features.
Sometimes Smalltalk feels a lot like CL to me, but a lot of the time
that's just general dynamic-language or OOP techniques I'm seeing in
common, so I try not to read too much into it, because I don't have
enough experience in ST to trust myself to get it right ... I know I
could easily end out very frustrated, trying to write Lisp in ST and
hating it.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Dorai Sitaram
Thomas F. Burdick <t...@whirlwind.OCF.Berkeley.EDU> wrote:
>Brian Campbell <lambd...@yahoo.com> writes:
>
>> How about the loop macro? I know there's a large amount of debate on it,
>> but I'm wondering what the people who are for it have to say about it,
>> since coming from scheme, I would just use tail-recursion.
>
>When you're iterating, it's usually more obvious to write the code in
>an iterative form, not a recursive one. LOOP is nice because it
>easily and clearly expresses a very large subset of the iterations
>people write. We all *can* read tail-recursive functions -- it's
>wanting to that's another story.
The LOOP syntax makes continuing implicit and exiting
explicit. The named-LET syntax makes continuing
explicit and exiting implicit. Because of this,
non-vanilla iterations require the fabrication and
mastery of ever more additional syntax in LOOP and no
additional syntax (not even for the explicit continue)
in named-LET.
--d
Kent M Pitman
Ding, ding, ding, ding
Shift of notation = unambiguous win with no loss? I don't think so.
When you change to explicit continuing, you also make all the state explicit
because the state must be visible in order to invoke the continuation syntax.
In LOOP, there may be multiple bits of state implicit to the efficient
execution of something. For example, LOOP makes collection of a list
efficient. We don't know whether it's via an NREVERSE at the end or an extra
variable being carried through that contains a pointer onto which NCONC'ing
can efficiently be done. When you make this explicit, you force the
programmer to have knowledge of the implementation of the "continue chain".
It's worth observing that there is a design trade-off being made, but
trade-offs work both ways. The design trade-off that LOOP makes is not
as simple as you portray it.
LOOP requires the user to be knowledgeable only about "outcomes" they want
from a LOOP and permits much less knowledge of competent "accumulation
techniques". Further, adding an extra accumulation that does not affect
the outcome can be done modularly, without the incremental repair of every
connectivity point in the continue-chain.
Marco Antoniotti
Brian Campbell <lambd...@yahoo.com> writes:
> In article <y6clmdy...@octagon.mrl.nyu.edu>,
> Marco Antoniotti <mar...@cs.nyu.edu> wrote:
>
> > Brian Campbell <lambd...@yahoo.com> writes:
> >
> > > Are there any good introductions to Common Lisp for people who are
> > > experienced in scheme? I would be especially interested in introductions
> > > to CLOS, and also any gotchas in moving from scheme to Common Lisp (like
> > > the defun/define distinction).
> >
> > I suggest this goes in the Cookbook.
>
> What is the Cookbook?
>
> >
> > IMHO the key issues are:
> >
> > 1 - Named LET's (easily substituted by a macro).
>
> This was the second major difference I noticed, and writing a macro to
> fix it was my first reflex.
A solution is this (of course this could be improved).
(defmacro named-let (name bindings &body forms)
`(labels ((,name ,(mapcar #'first bindings)
,@forms))
(,name ,@(mapcar #'second bindings))))
...
> > 3 - You do not need call/cc 98% of the time.
>
> I have never actually used call/cc in any real code I've written in
> scheme, but then again, I've never written the kind of thing that would
> use it. For that other 2% of the time, though, it's damn handy.
Most of the uses of call/cc are for hairy error handling and for
``multitasking'' (quotes mandatory). The first item is covered by the
CONDITION system in CL. The second one almost has a common interface
in the CLIM-SYS definition. Really, call/cc is not that useful since
it is too low level.
> This
> also ties into number 4; it's pretty useful for writing things like
> conditions which common lisp already has.
>
> By the way, are there any common lisps which have it? Or does it violate
> anything in the common lisp standard? It would be pretty handy for
> writing logical reasoning code with backtracking.
And why do you need call/cc to do that? A standard graph search
algorithm would satisfy your needs.
...
>
> How about the loop macro?
>
I would bundle that into the CLOS wagon. IMHO, this is really not that
hampers the use of CL by a Schemer.
Thomas F. Burdick
> In article <xcvu1sl...@whirlwind.OCF.Berkeley.EDU>,
> Thomas F. Burdick <t...@whirlwind.OCF.Berkeley.EDU> wrote:
> >Brian Campbell <lambd...@yahoo.com> writes:
> >
> >> How about the loop macro? I know there's a large amount of debate on it,
> >> but I'm wondering what the people who are for it have to say about it,
> >> since coming from scheme, I would just use tail-recursion.
> >
> >When you're iterating, it's usually more obvious to write the code in
> >an iterative form, not a recursive one. LOOP is nice because it
> >easily and clearly expresses a very large subset of the iterations
> >people write. We all *can* read tail-recursive functions -- it's
> >wanting to that's another story.
>
> The LOOP syntax makes continuing implicit and exiting explicit.
That's how iteration generally works.
> The named-LET syntax makes continuing explicit and exiting implicit.
That's how recursion generally works.
> Because of this, non-vanilla iterations require the fabrication and
> mastery of ever more additional syntax in LOOP and no additional
> syntax (not even for the explicit continue) in named-LET.
I disagree that all it takes is non-vanilla iterations before loops
get hairy; but when they do, so what? You either switch techniques,
or extend LOOP. I didn't claim that LOOP solves all your iteration
woes. That's part of its appeal, that it doesn't. It does work
nicely and easily for a very large subset of the iteration problems
you normally come across. It's very nice to have tools that aren't
all fully general -- specialists are much nicer in their appropriate
domain than generalists.
Kent M Pitman
> I didn't claim that LOOP solves all your iteration
> woes. That's part of its appeal, that it doesn't. It does work
> nicely and easily for a very large subset of the iteration problems
> you normally come across. It's very nice to have tools that aren't
> all fully general -- specialists are much nicer in their appropriate
> domain than generalists.
Nicely put.
The Scheme and functional programming crowd tends to cringe at our use
of keywords for what they would use lambda expressions to do. e.g.,
they might prefer:
(sort lst (lambda (x) (< (car x) (car y))))
over
(sort list #'< :key #'car)
But I still like the less general, more specialized one.
It reminds me of a realization I had after reading about Special and
General Relativity in science class in high school: that the names are
backward. Special Relativity (so-named because it is a specialization
of the full theory) is the one that's "generally useful"; General
Relativity (so-named because it's capable of applying in the most
general case), is the only that's only useful in special
circumstances, because it's more complex than Special Relativity and
even if it applies everywhere, it's just overkill for most cases.
Generality is a special-case need.
Special-cases are more generally needed.
Bijan Parsia
> * Brian Campbell <lambd...@yahoo.com>
> | Are there any good introductions to Common Lisp for people who are
> | experienced in scheme? I would be especially interested in introductions
> | to CLOS, and also any gotchas in moving from scheme to Common Lisp (like
> | the defun/define distinction).
>
> There is only one gotcha: Thinking that being experienced in Scheme helps
> when you want to learn Common Lisp. It does not. In fact, much evidence
> (i.e., past students) seems to indicate that it prevents you from
> learning Common Lisp. So to learn Common Lisp if you know Scheme, keep
> reminding yourself that any "Scheme ways" you think are similar are not.
It may help to *start* with the bits of Common Lisp that have no analogue
in Scheme. Say, CLOS. Perhaps starting with Keene's wonderful book.
After all, there's an *awful* lot of fun to be had "just" in CLOS and it's
quite distant from RS*R scheme. So the incentive to rely on "what you
know" is rather small, and you'll get used to the available reference
materials for Common Lisp. (I find that if the docs suck, or my ability to
use them is weak, I have a much harder time working properly with a
langauge where my builtin misunderstandings let me limp along :) I.e., I
find the Python documentation rather painful, so I tend to make a lot of
Smalltalk-thinking mistakes when starting up with Python. Then I remember
that lots of important stuff is in the "Tutorial" (which I *always*
forget!) and things improve.)
This particular advice might not hold if you are familiar with a CLOS like
Scheme object system (of which there are I few, I gather).
Hmm. I'll just through out that Norvig's *Paradigms of Artificial
Programming* might work well for Schemers. Perhaps reading chapter 3, "An
Overview of Lisp" (or the first three chapters), then 22, "Scheme: An
Uncommon Lisp" would be a good progression. If you're familiar with the
use of meta-circular interpreters to explicate langauges, and like that
;), his Scheme interpreter in Common Lisp might prove illuminating. (I
think Paul Graham has something like that in *On Lisp*, too.)
Cheers,
Bijan Parsia.
Lieven Marchand
> It reminds me of a realization I had after reading about Special and
> General Relativity in science class in high school: that the names are
> backward. Special Relativity (so-named because it is a specialization
> of the full theory) is the one that's "generally useful"; General
> Relativity (so-named because it's capable of applying in the most
> general case), is the only that's only useful in special
> circumstances, because it's more complex than Special Relativity and
> even if it applies everywhere, it's just overkill for most cases.
That's also a general point in titles of text books. High school text
books will be called "Advanced Algebra" etc. College ones just
"Algebra", and graduate level ones "An introduction to ...". The
absolutely killer book on number theory, where graduate level
mathematicians can spend a few years on, is called "Basic number
theory" by Weil.
--
Lieven Marchand <m...@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Bruce Lewis
> The Scheme and functional programming crowd tends to cringe at our use
> of keywords for what they would use lambda expressions to do. e.g.,
> they might prefer:
>
> (sort lst (lambda (x) (< (car x) (car y))))
>
> over
>
> (sort list #'< :key #'car)
The RnRS authors may lean toward a few general constructs over a large
number of specialized ones, but I don't think you can characterize the
"Scheme and functional programming crowd" that way. There is a
diversity of style. Kawa Scheme (and likely other implementations)
includes CL-style keywords, albeit not all the nice CL &foo specifiers.
Some might prefer:
(define (sort-key lst comparator key)
(sort lst (lambda (a b) (comparator (key a) (key b)))))
Though I admit it would be nicer to just do
(sort lst < key: car)
--
<brlewis@[(if (brl-related? message) ; Bruce R. Lewis
"users.sourceforge.net" ; http://brl.sourceforge.net/
"alum.mit.edu")]>