Hi there,
I like the Apress' books about programming ( I already read their book
on Groovy and Grails, and I'm currently reading the Ruby one). I saw
they have a book on Common Lisp, too. Following the trend, I'd like to
buy it (since I'm very interested in learning Lisp, as it's like
nothing I've ever seen before).
It's more expensive than most of their books. If I buy it, it will be
their first book I actually bought.
So, is it worth the price? Will it cover the principals of Common
Lisp?
Thanks you guys for reading this ;)
See ya
p0Eta <·······@gmail.com> writes:
> Hi there,
>
> I like the Apress' books about programming ( I already read their book
> on Groovy and Grails, and I'm currently reading the Ruby one). I saw
> they have a book on Common Lisp, too. Following the trend, I'd like to
> buy it (since I'm very interested in learning Lisp, as it's like
> nothing I've ever seen before).
>
> It's more expensive than most of their books. If I buy it, it will be
> their first book I actually bought.
>
> So, is it worth the price? Will it cover the principals of Common
> Lisp?
I think it's dead sexy, and well worth buying in hardcopy. But you can
also preview the whole thing at http://gigamonkeys.com/book/ to see if
it's what you're looking for.
Zach
From: Raffael Cavallaro
Subject: Re: Is Apress' book good?
Date:
Message-ID: <gv9ofm$t69$1@aioe.org>
On 2009-05-23 16:30:28 -0400, p0Eta <·······@gmail.com> said:
> So, is it worth the price? Will it cover the principals of Common
> Lisp?
I read the pdf version as it was being written and revised, then bought
the dead tree version when it was released. I think it's definitely
worth having if you're a newcomer to common lisp. Also worth
considering are David Lamkins' _Successful Lisp_ and Paul Graham's ANSI
common lisp, though neither of these latter two are practical,
project-based treatments.
--
Raffael Cavallaro, Ph.D.
On May 24, 12:05 am, Raffael Cavallaro
<················@pas.espam.s.il.vous.plait.mac.com> wrote:
> On 2009-05-23 16:30:28 -0400, p0Eta <·······@gmail.com> said:
>
> > So, is it worth the price? Will it cover the principals of Common
> > Lisp?
>
> I read the pdf version as it was being written and revised, then bought
> the dead tree version when it was released. I think it's definitely
> worth having if you're a newcomer to common lisp. Also worth
> considering are David Lamkins' _Successful Lisp_ and Paul Graham's ANSI
> common lisp, though neither of these latter two are practical,
> project-based treatments.
I think it's worth having a hard-copy of the book, because you'll want
to read it and have your screen accessible at the same time. However,
you should probably poke around the site anyways, because he has some
good software for starting out with Lisp available there.
One note: I found the discussion of packages in this book to not be
entirely clear. Although Peter Seibel tells you a fair amount about
defining packages, he doesn't explain in great details the ideas
behind the package system. I think that the best discussion of
packages at their purest is the "Idiot's Guide to Common Lisp
Packages", a short PDF available for free here:
http://www.flownet.com/ron/packages.pdf
I'd reccommend that when you get to the chapter on packages in PCL,
you read this document first.
Enjoy Lisp! If you like Ruby, I'll briefly quote Matz here: "Some may
say Ruby is a bad rip-off of Lisp or Smalltalk, and I admit that. But
it is nicer to ordinary people."
So, you're about to find out what Ruby is trying to emulate. Enjoy
Lisp!
- Adlai
On 24 Mai, 00:39, Adlai <·········@gmail.com> wrote:
> One note: I found the discussion of packages in this book to not be
> entirely clear. Although Peter Seibel tells you a fair amount about
> defining packages, he doesn't explain in great details the ideas
> behind the package system. I think that the best discussion of
> packages at their purest is the "Idiot's Guide to Common Lisp
> Packages", a short PDF available for free here:http://www.flownet.com/ron/packages.pdf
This paper describes to some detail how packages work technically, but
it doesn't show you how one can make good use of them. Actually I do
not know tutorial that describes this. The CL package system offers
you alot of rope - its your thing if you can make good use of it.
Similarily to CLOS - the only way to learn how packages really work is
by reading alot of CL code.
ciao,
Jochen
···@crispylogics.com wrote:
> On 24 Mai, 00:39, Adlai <·········@gmail.com> wrote:
>
>> One note: I found the discussion of packages in this book to not be
>> entirely clear. Although Peter Seibel tells you a fair amount about
>> defining packages, he doesn't explain in great details the ideas
>> behind the package system. I think that the best discussion of
>> packages at their purest is the "Idiot's Guide to Common Lisp
>> Packages", a short PDF available for free here:http://www.flownet.com/ron/packages.pdf
>
> This paper describes to some detail how packages work technically, but
> it doesn't show you how one can make good use of them. Actually I do
> not know tutorial that describes this. The CL package system offers
> you alot of rope - its your thing if you can make good use of it.
> Similarily to CLOS - the only way to learn how packages really work is
> by reading alot of CL code.
Some (very general) rules of thumb are listed here:
http://article.gmane.org/gmane.comp.lang.lightweight/3891
Especially the advice to use large packages is important. It's a typical
beginner's mistake to make packages too fine-grained, and it never pays off.
(I don't agree with Joe's assessment, btw. I think Common Lisp's package
system is great. But that's a different discussion... ;)
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 24 Mai, 11:26, Pascal Costanza <····@p-cos.net> wrote:
> ····@crispylogics.com wrote:
> > On 24 Mai, 00:39, Adlai <·········@gmail.com> wrote:
>
> >> One note: I found the discussion of packages in this book to not be
> >> entirely clear. Although Peter Seibel tells you a fair amount about
> >> defining packages, he doesn't explain in great details the ideas
> >> behind the package system. I think that the best discussion of
> >> packages at their purest is the "Idiot's Guide to Common Lisp
> >> Packages", a short PDF available for free here:http://www.flownet.com/ron/packages.pdf
>
> > This paper describes to some detail how packages work technically, but
> > it doesn't show you how one can make good use of them. Actually I do
> > not know tutorial that describes this. The CL package system offers
> > you alot of rope - its your thing if you can make good use of it.
> > Similarily to CLOS - the only way to learn how packages really work is
> > by reading alot of CL code.
>
> Some (very general) rules of thumb are listed here:http://article.gmane.org/gmane.comp.lang.lightweight/3891
>
> Especially the advice to use large packages is important. It's a typical
> beginner's mistake to make packages too fine-grained, and it never pays off.
Jochen Schmidt's Personal Guidelines for Packages
-------------------------------------------------
1) Define packages declaratively (DEFPACKAGE)
Use DEFPACKAGE - It is seldom a good idea to use USE-PACKAGE or IMPORT
directly within your code. Those functions can be useful within the
listener or when writing your own framework of package managing
functions/macros though.
2) Do not use packages too fine grained
The general advice to use relatively large packages is a good one.
There is not much use for more than one package for very small
projects. It is a bad idea to define a package per class for example.
On the other side it is also not a good idea to use less than one
(dedicated) package ;-) for projects aren't just little experiments.
If a project grows big enough that you can split it up in different
non-trivial modules - it can be a good idea to use different packages
though.
3) It is a good idea to distinguish between implementation and
interface
If you want to control the public interface of a module/library, it
can be a good idea to define that public interface as a package
exporting all symbols that make it up. You can then define an
implementation package which just USEs the interface package(s).
4) Make good use of features like shadowing imports
An implementation package is your playground - take some time to set
it up in a way that is comfortable for you. You can shadow symbols
coming from other (used) packages in your implementation package. You
can use your own version of DEFCLASS which defines persistent classes
or you can override arithmetic functions like +, * or /. Actually I
think using the package system like this may be controversial, because
some people may have no good feelings about changing the semantics of
common names this way, but I think there are good reasons to do so. If
you're writing some MOP heavy stuff, you can fix incompatibilities
between implementations by defining your own package local DEFCLASS
a.s.o. I've also written some code which made heavy use of modular
arithmetic; overloading common arithmetic functions can then be very
helpful. I've also shadowed arithmetic functions when writing heavily
optimized, still readable code - packages are a very versatile tool to
make such compile time optimization possible (besides things like
compiler macros). A good rule of thumb is that while it can be a good
idea to shadow symbols of used packages - it is not always a good idea
to export those again. (exception "conduits" - see below)
5) Using packages is often a better idea than using symbol-prefixes
Some CL programmers tend to prefix their functions to make them stick
out between others. The reason is often that it makes USEing such a
package easier because you do not have to handle so much conflicts. I
often find that using nicknames is a better idea. It's not that
difficult to setup a project to setup nicknames properly. I think
package-local aliases would make this much more accessible though.
6) Look at Tim Bradshaws Conduits
I think it is a very good idea to look at Tim Bradshaws Conduits
(http://www.tfeb.org/lisp/hax.html#CONDUITS). They make mixing and
matching symbols from different packages alot easier. It's code is an
example of 4) that you can do useful things by shadowing standard
names (like DEFPACKAGE, EXPORT, UNEXPORT, RENAME-PACKAGE and DELETE-
PACKAGE).
Packages are more than a mean to circumvent name collisions - they are
a very capable tool for abstraction.
ciao,
Jochen
Adlai <·········@gmail.com> writes:
> One note: I found the discussion of packages in this book to not be
> entirely clear. Although Peter Seibel tells you a fair amount about
> defining packages, he doesn't explain in great details the ideas
> behind the package system. I think that the best discussion of
> packages at their purest is the "Idiot's Guide to Common Lisp
> Packages", a short PDF available for free here:
> http://www.flownet.com/ron/packages.pdf
That document is not without flaws. For example, it assumes that
packages created without an explicit use list will use the COMMON-LISP
package. That's not the case in SBCL.
Zach
In article <··············@unnamed.xach.com>,
Zach Beane <····@xach.com> wrote:
> Adlai <·········@gmail.com> writes:
>
> > One note: I found the discussion of packages in this book to not be
> > entirely clear. Although Peter Seibel tells you a fair amount about
> > defining packages, he doesn't explain in great details the ideas
> > behind the package system. I think that the best discussion of
> > packages at their purest is the "Idiot's Guide to Common Lisp
> > Packages", a short PDF available for free here:
> > http://www.flownet.com/ron/packages.pdf
>
> That document is not without flaws. For example, it assumes that
> packages created without an explicit use list will use the COMMON-LISP
> package. That's not the case in SBCL.
Which is an incompatibility with most other implementations.
The idea behind giving a default to the used packages
in
(DEFPACKAGE "FOO")
is: in interactive use at the REPL one can
create a package with the usual default used packages so
that the local extended Lisp is available - just by typing a
simple DEFPACKAGE and then IN-PACKAGE (or whatever you would use
to switch a package). The user would not need to lookup
what the used package defaults are on this Lisp.
In SBCL I would need to use something like
(make-package "FOO" :use (package-use-list "CL-USER"))
to create a new package with the usual default extensions.
* (package-use-list "FOO")
(#<PACKAGE "COMMON-LISP"> #<PACKAGE "SB-ALIEN"> #<PACKAGE "SB-DEBUG">
#<PACKAGE "SB-EXT"> #<PACKAGE "SB-GRAY"> #<PACKAGE "SB-PROFILE">)
In CLtL1 one could just use (IN-PACKAGE "FOO") and it
would both create the package (if it does not exist) and
switch *package* to it. CLtL2 gives the following rationale
for changes to IN-PACKAGE:
Rationale: Many existing implementations of Common Lisp happen
to have violated the first edition specification, providing as
the default not only the lisp package but also (or instead) a
package containing implementation-dependent language extensions.
This is for good reason: usually it is much more convenient to
the user for the default :use list to be the entire,
implementation-dependent, extended language rather than only
the facilities specified in this book. The X3J13 vote simply
legitimizes existing practice.
SBCL then took the freedom to use NO package.
* (defpackage "FOO")
#<PACKAGE "FOO">
* (package-use-list "FOO")
NIL
--
http://lispm.dyndns.org/
Rainer Joswig <······@lisp.de> writes:
> In article <··············@unnamed.xach.com>,
> Zach Beane <····@xach.com> wrote:
>
>> Adlai <·········@gmail.com> writes:
>>
>> > One note: I found the discussion of packages in this book to not be
>> > entirely clear. Although Peter Seibel tells you a fair amount about
>> > defining packages, he doesn't explain in great details the ideas
>> > behind the package system. I think that the best discussion of
>> > packages at their purest is the "Idiot's Guide to Common Lisp
>> > Packages", a short PDF available for free here:
>> > http://www.flownet.com/ron/packages.pdf
>>
>> That document is not without flaws. For example, it assumes that
>> packages created without an explicit use list will use the COMMON-LISP
>> package. That's not the case in SBCL.
>
> Which is an incompatibility with most other implementations.
> The idea behind giving a default to the used packages
> in
>
> (DEFPACKAGE "FOO")
>
> is: in interactive use at the REPL one can
> create a package with the usual default used packages so
> that the local extended Lisp is available - just by typing a
> simple DEFPACKAGE and then IN-PACKAGE (or whatever you would use
> to switch a package). The user would not need to lookup
> what the used package defaults are on this Lisp.
> In SBCL I would need to use something like
>
> (make-package "FOO" :use (package-use-list "CL-USER"))
>
> to create a new package with the usual default extensions.
>
> * (package-use-list "FOO")
>
> (#<PACKAGE "COMMON-LISP"> #<PACKAGE "SB-ALIEN"> #<PACKAGE "SB-DEBUG">
> #<PACKAGE "SB-EXT"> #<PACKAGE "SB-GRAY"> #<PACKAGE "SB-PROFILE">)
>
>
> In CLtL1 one could just use (IN-PACKAGE "FOO") and it
> would both create the package (if it does not exist) and
> switch *package* to it. CLtL2 gives the following rationale
> for changes to IN-PACKAGE:
>
> Rationale: Many existing implementations of Common Lisp happen
> to have violated the first edition specification, providing as
> the default not only the lisp package but also (or instead) a
> package containing implementation-dependent language extensions.
> This is for good reason: usually it is much more convenient to
> the user for the default :use list to be the entire,
> implementation-dependent, extended language rather than only
> the facilities specified in this book. The X3J13 vote simply
> legitimizes existing practice.
>
> SBCL then took the freedom to use NO package.
>
> * (defpackage "FOO")
>
> #<PACKAGE "FOO">
>
> * (package-use-list "FOO")
>
> NIL
I agree that it may be more convenient to the user to have some
meaningful default :use list.
However, if this default is not specified to be ("CL"), then it poses
a problem to the newbies and tutorial writers: to be able to write a
tutorial that is not specific (in non obvious ways!) to a given
implementation, the tutorial writer has to write :USE ("CL").
Therefore I support the SBCL authors' decision, because it forces
tutorial writers to do the right thing.
Also, I think it's a good thing to have to use fully qualified symbols
from implementation specific packages. This renders clear when some
source is implementation specific.
--
__Pascal Bourguignon__
p0Eta wrote:
> Hi there,
>
> I like the Apress' books about programming ( I already read their book
> on Groovy and Grails, and I'm currently reading the Ruby one). I saw
> they have a book on Common Lisp, too. Following the trend, I'd like to
> buy it (since I'm very interested in learning Lisp, as it's like
> nothing I've ever seen before).
>
> It's more expensive than most of their books. If I buy it, it will be
> their first book I actually bought.
>
> So, is it worth the price? Will it cover the principals of Common
> Lisp?
It's an excellent introduction to Common Lisp and it covers a lot of
ground. You can't go wrong with this one.
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/