From: Pascal Costanza
Subject: My guide to Lisp
Date: 
Message-ID: <3D64F205.13C55ED6@cs.uni-bonn.de>
Hi everybody,

I am relatively new to the Lisp world. Because of my involvement with
Richard Gabriel's Feyerabend project I have been confronted with Common
Lisp and digged deeply into it for the last few months. I have written a
summary of what I have found out and made it available recently at
http://www.pascalcostanza.de/lisp/guide.html. Please let me know what
you think.

All the best,
Pascal

--
Pascal Costanza               University of Bonn
···············@web.de        Institute of Computer Science III
http://www.pascalcostanza.de  R�merstr. 164, D-53117 Bonn (Germany)

From: Duane Rettig
Subject: Re: My guide to Lisp
Date: 
Message-ID: <4k7mipxu3.fsf@beta.franz.com>
Pascal Costanza <········@cs.uni-bonn.de> writes:

> Hi everybody,
> 
> I am relatively new to the Lisp world. Because of my involvement with
> Richard Gabriel's Feyerabend project I have been confronted with Common
> Lisp and digged deeply into it for the last few months. I have written a
> summary of what I have found out and made it available recently at
> http://www.pascalcostanza.de/lisp/guide.html. Please let me know what
> you think.

This looks like a good compendium, with good references and
good organization.

Here are some comments I have, after my first time through the
document:


===

I like the choice you've made of Common Lisp over Scheme, but I also
think you are being too kind to Scheme.  In section 2, you say "... If
you mainly want to do academic research and, for example, want to
experiment with language extenstions, you could opt for Scheme..."

This statement is true enough, but because it is part of a comparison,
it implies that Scheme is better for either academic research or
language extensions than CL.  I will not argue the point about
academic research, since Scheme probably has a larger presence in the
academic world (though in my opinion only through usage, not by merit).
However, I strongly disagree that Scheme is the choice for language
extensions.  Scheme proponents will argue that because Scheme is
simpler than CL, it is easier to extend.  But I argue that because
the Scheme gestalt is in fact much stricter than CL, that it is in
fact much _harder_ to extend Scheme into new languages, maintaining
that Scheme gestalt, than it is to extend CL while maintaining a CL
gestalt.  Indeed, what make CL so applicable to Commercial efforts is
precisely the ability of programmers to easily build up the language
to that of the application domain.

===

In section 4, Some Firt Obstacles, the thrid bullet, you mention that
some people think of Lisp as only lists as data structures.  In
addition to the reason you gave, you might add another: the name
Lisp itself (LISt Processing).  Your rebuttal is good.

===

Part 2:

===

In section 8, Reference material, you cite CLtL2 as being a good
reference book.  I strongly disagree with this; it is indeed a good
book to learn from initially, but with the excellent linking and
cross-referencing that the actual Ansi Spec has, only the spec should
ever be recommended as a reference.

Also, you might want to add the hyperlinked version that Franz provides:
http://www.franz.com/support/documentation/6.2/ansicl/ansicl.htm

===

Section 11: Macros:  Third bullet:

You say "Macros can call other macros and functions ...".  Technically,
macros aren't called; they are expanded.  So a more correct way to say
this is "Macros can contain forms which represent further macroexpansions
and/or function calls ..."

===

Also in section 11:  The discussion of hygene is an interesting one, but
perhaps too heavy for an introductory document.  Others might disagree
with this.  However, it might improve the layout of the document to add
another section close to the bottom (maybe called "Esoteric problems and
Considerations") where discussions like this could be placed.

===

Section 12:  CLOS/MOP standardization:

CLOS is definitely part of the Ansi CL spec.  Any implementation that
doesn't implement CLOS does not conform (usually these lisps are
called CLtL1 lisps, because they had not continued to follow the ANSI
spec as it was developed).

As for the MOP, it is definitely not part of the ANSI standard.  However,
Gregor Kiczales, in his part in developing CLOS and the MOP, created
a system called PCL (portable Common LOOPS) which became the basis for
CLOS when it was standardized and which also became the basis for most
CLOS implementations.  Because the implementation base was so strong
for PCL/CLOS, the MOP (especially as it is described in AMOP) became
de-facto standard (though still not part of the ANSI CL spec).  This
may help clarify things for you.

===

Also section 12:  No need to apologize for the Aspect-J joke; you're
talking to CL-ers! :-)

===

Section 14: Conditions:

Where you say "can also be signalled where there is no problem ..."
you could add some wording to include the idea that many problems are
correctable on-the-fly.  For example, unbound-variable conditions
usually have restarts that allow the user to setq the variable and
use that value, or to use a value without setqing the variable, etc.
Also, correctable conditions can be corrected programmatically as well
as interactively.

===




Reference URLs:

http://c2.com/cgi/wiki?ScopeAndClosures:

===
The section on dynamic scoping starts out by saying "Well, that's the
standard behavior in Java ..." but it is almost certain that you are
intending to describe lexical-scoping instead of dynamic scoping - it
seems you are tying the two sections toggether, but the wording might
cause confusion.  I suggest something like "It might be apparent that
Lexical Scoping is the standard behavior in Java ..."  and then the
transition to dynamic-scoping is clear.

===


-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Pascal Costanza
Subject: Re: My guide to Lisp
Date: 
Message-ID: <3D664F56.80D057E2@cs.uni-bonn.de>
Duane Rettig wrote:
> 
> Pascal Costanza <········@cs.uni-bonn.de> writes:

[...]

> > http://www.pascalcostanza.de/lisp/guide.html. Please let me know what
> > you think.
> 
> This looks like a good compendium, with good references and
> good organization.
> 
> Here are some comments I have, after my first time through the
> document:
 
> ===
> 
> Also in section 11:  The discussion of hygene is an interesting one, but
> perhaps too heavy for an introductory document.  Others might disagree
> with this.  However, it might improve the layout of the document to add
> another section close to the bottom (maybe called "Esoteric problems and
> Considerations") where discussions like this could be placed.

It might really be too heavy for an introduction, but the problem I have
faced when I tried to make up my mind over Common Lisp vs. Scheme is
that you can't avoid to be confronted with this issue. It caused me a
lot of trouble to understand the issue and to realize that it's not as
important as is claimed by some.

The message I want to give is: forget about it - don't waste your time
like I did! ;)

I will make this more clear in the new version.

> ===
> 
> Section 12:  CLOS/MOP standardization:
> 
> CLOS is definitely part of the Ansi CL spec.  Any implementation that
> doesn't implement CLOS does not conform (usually these lisps are
> called CLtL1 lisps, because they had not continued to follow the ANSI
> spec as it was developed).
> 
> As for the MOP, it is definitely not part of the ANSI standard. 

To be honest, I haven't taken enough time yet to understand this issue.
The problem I have is: are things like before-, after- and around
advices part of CLOS or part of MOP? I understand that the MOP is not
part of ANSI CL, but is there a brief description of what features
belong to CLOS and what belong to the MOP?

> ===
> 
> Also section 12:  No need to apologize for the Aspect-J joke; you're
> talking to CL-ers! :-)

Well, perhaps Gregor Kiczales is going to read this guide at some stage
- and I don't want to ruin my career. ;-)

Pascal

--
Pascal Costanza               University of Bonn
···············@web.de        Institute of Computer Science III
http://www.pascalcostanza.de  R�merstr. 164, D-53117 Bonn (Germany)
From: Thomas F. Burdick
Subject: Re: My guide to Lisp
Date: 
Message-ID: <xcvznvdnzu3.fsf@conquest.OCF.Berkeley.EDU>
Pascal Costanza <········@cs.uni-bonn.de> writes:

> Duane Rettig wrote:
>
> > Section 12:  CLOS/MOP standardization:
> > 
> > CLOS is definitely part of the Ansi CL spec.  Any implementation that
> > doesn't implement CLOS does not conform (usually these lisps are
> > called CLtL1 lisps, because they had not continued to follow the ANSI
> > spec as it was developed).
> > 
> > As for the MOP, it is definitely not part of the ANSI standard. 
> 
> To be honest, I haven't taken enough time yet to understand this issue.
> The problem I have is: are things like before-, after- and around
> advices part of CLOS or part of MOP? I understand that the MOP is not
> part of ANSI CL, but is there a brief description of what features
> belong to CLOS and what belong to the MOP?

Well, you could look through the "Objects" chapter of the spec, and
everything that's not in there, obviously isn't in there :).  Part of
the problem might be that CLOS already provides some significant
facilities for meta-programming -- to the extent that you can do a lot
of Aspect-oriented stuff using only the ANSI standardized facilities.
So the MOP isn't the collection of all the meta-programming facilities
of CLOS, it's just the ones that aren't already in the ANSI standard.

BTW, it's a very nice introduction that I'll definately recommend to
others.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Barry Margolin
Subject: Re: My guide to Lisp
Date: 
Message-ID: <Ans99.6$9w4.1189@paloalto-snr1.gtei.net>
In article <·················@cs.uni-bonn.de>,
Pascal Costanza  <········@web.de> wrote:
>Duane Rettig wrote:
>> As for the MOP, it is definitely not part of the ANSI standard. 
>
>To be honest, I haven't taken enough time yet to understand this issue.
>The problem I have is: are things like before-, after- and around
>advices part of CLOS or part of MOP? I understand that the MOP is not
>part of ANSI CL, but is there a brief description of what features
>belong to CLOS and what belong to the MOP?

Before-, after-, and around-methods are just ordinary CLOS.  The MOP is the
part of CLOS that allows for introspection about classes and methods.
There are a couple of MOP-related functions that managed to sneak into ANSI
CL, such as ADD-METHOD and ENSURE-GENERIC-FUNCTION, but not much of this.

A good way to tell whether something is part of basic CLOS or the MOP is
whether any of its arguments are required to be class, method, or
generic-function objects.  Functions like MAKE-INSTANCE or CHANGE-CLASS
don't fall into this category; even though they accept a class object, they
also accept a class name in its place, and MOP functions generally don't
provide this convenience layer.

-- 
Barry Margolin, ······@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Duane Rettig
Subject: Re: My guide to Lisp
Date: 
Message-ID: <41y8pjzho.fsf@beta.franz.com>
Pascal Costanza <········@cs.uni-bonn.de> writes:

> Duane Rettig wrote:
> > 
> > Pascal Costanza <········@cs.uni-bonn.de> writes:
> 
> [...]
> 
> > > http://www.pascalcostanza.de/lisp/guide.html. Please let me know what
> > > you think.
> > 
> > This looks like a good compendium, with good references and
> > good organization.
> > 
> > Here are some comments I have, after my first time through the
> > document:
>  
> > ===
> > 
> > Also in section 11:  The discussion of hygene is an interesting one, but
> > perhaps too heavy for an introductory document.  Others might disagree
> > with this.  However, it might improve the layout of the document to add
> > another section close to the bottom (maybe called "Esoteric problems and
> > Considerations") where discussions like this could be placed.
> 
> It might really be too heavy for an introduction, but the problem I have
> faced when I tried to make up my mind over Common Lisp vs. Scheme is
> that you can't avoid to be confronted with this issue. It caused me a
> lot of trouble to understand the issue and to realize that it's not as
> important as is claimed by some.
> 
> The message I want to give is: forget about it - don't waste your time
> like I did! ;)
> 
> I will make this more clear in the new version.

OK, I'll look forward to your next iteration.

> > Section 12:  CLOS/MOP standardization:
> > 
> > CLOS is definitely part of the Ansi CL spec.  Any implementation that
> > doesn't implement CLOS does not conform (usually these lisps are
> > called CLtL1 lisps, because they had not continued to follow the ANSI
> > spec as it was developed).
> > 
> > As for the MOP, it is definitely not part of the ANSI standard. 
> 
> To be honest, I haven't taken enough time yet to understand this issue.
> The problem I have is: are things like before-, after- and around
> advices part of CLOS or part of MOP? I understand that the MOP is not
> part of ANSI CL, but is there a brief description of what features
> belong to CLOS and what belong to the MOP?

Barry has already given you a good rule-of-thumb.  But I am reading a
basic misunderstanding that it seems many CL users might have.  It seems
that people think that CLOS and MOP are two separate entities, and that
they are disjoint.  This is not true.  MOP describes a larger body of
work than CLOS, but they are for the most part compatible, and MOP just
describes _more_.  A Venn diagram of the two would place CLOS's circle
almost entirely within MOP's circle.

So _my_ rule-of-thumb is: if it is contained in the AMOP but not in
the ANSI spec, then it is MOP-only.  If it is in both the Ansi Spec and
the AMOP, it can probably be considered CLOS only.  If it is in the
Ansi spec but not at all in the AMOP, then it probably doesn't have
anything to do with CLOS or the MOP anyway.

You can search the ANSI spec by using our htdig search engine:

http://www.franz.com/search/index.lhtml#ansispec


> > Also section 12:  No need to apologize for the Aspect-J joke; you're
> > talking to CL-ers! :-)
> 
> Well, perhaps Gregor Kiczales is going to read this guide at some stage
> - and I don't want to ruin my career. ;-)

Well, if your career with AspectJ becomes somehow ruined, remember the
(now old) addage: "Don't wait for next week's version of AspectJ - you
can already do everything with Common Lisp right now!"  :-)

-- 
Duane Rettig    ·····@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182   
From: Matthew Danish
Subject: Re: My guide to Lisp
Date: 
Message-ID: <20020823044710.L334@meddle.res.cmu.edu>
On Thu, Aug 22, 2002 at 04:15:33PM +0200, Pascal Costanza wrote:
> Hi everybody,
> 
> I am relatively new to the Lisp world. Because of my involvement with
> Richard Gabriel's Feyerabend project I have been confronted with Common
> Lisp and digged deeply into it for the last few months. I have written a
> summary of what I have found out and made it available recently at
> http://www.pascalcostanza.de/lisp/guide.html. Please let me know what
> you think.

Thank you for the effort you've put into compiling this summary.  Here
are a few things I noticed while perusing it:

*  ``(The parameter "t" states that this should be printed to standard
   output.)''

   This is rather confusing to someone who doesn't know much about CL.
   It seems to indicate that T means "standard output", whereas it would
   be better stated that "the specified behavior of format when T
   (boolean truth) is the stream argument is to print to standard
   output"

*  ``CLISP, obviously almost all platforms''

  It's only obvious after you click the link and read a little about it,
  though.

*  Other implementations, which are in reasonably working order:
   - CMUCL http://www.cons.org/cmucl/
   - SBCL http://sbcl.sourceforge.net/
   - OpenMCL http://www.clozure.com/openmcl/

   (also, why PowerLisp if it's not really an ANSI CL?)

*  ``Macros can be understood as functions that are evaluated at
   compile-time.''

   No.  Macros can be understood as functions which accept code as
   arguments and return code in turn, but they are not in any way tied
   to compile-time.  The specifics of macroexpansion-time are left to
   the implementation.

*  ``allows for manipulation of class hierarchies and message dispatch
   at run-time.''

   Do you mean "method" instead of "message", here?

*  ``(loop for i from 1 to 10 (format t "*"))''

   (loop for i from 1 to 10 do (format t "*"))

   While I can't speak for the designers of the LOOP facility myself, I
   find it to facilitate the expression of many complicated iterations
   which would be a pain to do using the other somewhat more cryptic or
   less expressive constructs available in the standard.

   I would cite LOOP as an example of a domain-specific language for the
   domain of iteration.  SERIES is another one.  That these macros can
   be written using only ANSI CL is also of note.

;; Here's a more interesting example of LOOP
(defun fib (n)
  "A list of fibonacci numbers up to n"
  (loop for a = 1 then (+ a b)
	and b = 0 then a  ; stepping in parallel
	repeat n
	collect b))

*  Packages

   Packages are not for bundling definitions but for containing symbols.
   This is a significant distinction between the CL package system and a
   code module system that many people often miss (probably due to
   terminology confusion).  Symbols are interned in packages--packages
   do not form encapsulation for code.  They exist to prevent symbol
   namespace clashes.


-- 
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
From: Raymond Toy
Subject: Re: My guide to Lisp
Date: 
Message-ID: <4nznvdn312.fsf@rtp.ericsson.se>
>>>>> "Matthew" == Matthew Danish <·······@andrew.cmu.edu> writes:

    Matthew>    I would cite LOOP as an example of a domain-specific language for the
    Matthew>    domain of iteration.  SERIES is another one.  That these macros can
    Matthew>    be written using only ANSI CL is also of note.

Not quite.  SERIES uses COMPILER-LET which is no longer part of ANSI
CL, although just about every Lisp has compiler-let somewhere.  If I
were smarter, I'd replace compiler-let with macrolet or whatever, but
I'm not smart enough.

Ray
From: Jock Cooper
Subject: Re: My guide to Lisp
Date: 
Message-ID: <m3vg61ze8r.fsf@jcooper02.sagepub.com>
Matthew Danish <·······@andrew.cmu.edu> writes:

> On Thu, Aug 22, 2002 at 04:15:33PM +0200, Pascal Costanza wrote:
> > Hi everybody,
> > 
> > I am relatively new to the Lisp world. Because of my involvement with
> > Richard Gabriel's Feyerabend project I have been confronted with Common
> > Lisp and digged deeply into it for the last few months. I have written a
> > summary of what I have found out and made it available recently at
> > http://www.pascalcostanza.de/lisp/guide.html. Please let me know what
> > you think.
> 
> Thank you for the effort you've put into compiling this summary.  Here
> are a few things I noticed while perusing it:
> 
> *  ``(The parameter "t" states that this should be printed to standard
>    output.)''
> 
>    This is rather confusing to someone who doesn't know much about CL.
>    It seems to indicate that T means "standard output", whereas it would
>    be better stated that "the specified behavior of format when T
>    (boolean truth) is the stream argument is to print to standard
>    output"
> 
I would go a step further and just take out that parenthetical comment
altogether.  At that point you are talking about Lisp forms--a 
fundamental aspect of the language.  I don't think the meaning of a 
specific argument for a specific function is relevant here. Even if
worded clearly IMO it would still confuse the beginner, who might wonder 
why you were talking about forms, and now are explaining the meaning of 
't' when given as the second argument of some function called 'format'.
From: Frode Vatvedt Fjeld
Subject: Re: My guide to Lisp
Date: 
Message-ID: <2hbs7uaqw9.fsf@vserver.cs.uit.no>
Matthew Danish <·······@andrew.cmu.edu> writes:

> Macros can be understood as functions which accept code as arguments
> and return code in turn, but they are not in any way tied to
> compile-time.  The specifics of macroexpansion-time are left to the
> implementation.

I don't think this is entirely correct. The CLHS says:

  3.2.2.2 Minimal Compilation

     o [..]

     o All macro and symbol macro calls appearing in the source code
       being compiled are expanded at compile time in such a way that
       they will not be expanded again at run time. macrolet and
       symbol-macrolet are effectively replaced by forms corresponding
       to their bodies in which calls to macros are replaced by their
       expansions.

-- 
Frode Vatvedt Fjeld
From: Pascal Costanza
Subject: Re: My guide to Lisp
Date: 
Message-ID: <3D665F67.6B7CD271@cs.uni-bonn.de>
Matthew Danish wrote:
> 
> On Thu, Aug 22, 2002 at 04:15:33PM +0200, Pascal Costanza wrote:

[...]

> > http://www.pascalcostanza.de/lisp/guide.html. Please let me know what
> > you think.
> 
> Thank you for the effort you've put into compiling this summary.  Here
> are a few things I noticed while perusing it:

[...]

> *  ``CLISP, obviously almost all platforms''
> 
>   It's only obvious after you click the link and read a little about it,
>   though.

This was a translation error. I have changed it to "apparently". The
German language uses one and the same word for both "apparently" and
"obviously" (and also "seemingly", "evidently", and so on)!

> *  ``allows for manipulation of class hierarchies and message dispatch
>    at run-time.''
> 
>    Do you mean "method" instead of "message", here?

I have learned the following terminology: messages are sent to objects,
and message dispatch consists of selecting the appropriate method for
this specific object. So you send and dispatch messages, and methods get
executed.

Is the terminology different in CLOS?

> *  Packages
> 
>    Packages are not for bundling definitions but for containing symbols.
>    This is a significant distinction between the CL package system and a
>    code module system that many people often miss (probably due to
>    terminology confusion).  Symbols are interned in packages--packages
>    do not form encapsulation for code.  They exist to prevent symbol
>    namespace clashes.

I am a little bit confused: if you bundle (assemble, collect - what's
the word?) symbols into packages, this also separates (at least in some
sense) their definitions.

I know that packages don't provide encapsulation in the sense of access
rights, but I haven't claimed that.

What am I missing?

Pascal

--
Pascal Costanza               University of Bonn
···············@web.de        Institute of Computer Science III
http://www.pascalcostanza.de  R�merstr. 164, D-53117 Bonn (Germany)
From: Erann Gat
Subject: Re: My guide to Lisp
Date: 
Message-ID: <gat-2308021014390001@192.168.1.52>
In article <·················@cs.uni-bonn.de>, ········@web.de wrote:

> > *  Packages
> > 
> >    Packages are not for bundling definitions but for containing symbols.
> >    This is a significant distinction between the CL package system and a
> >    code module system that many people often miss (probably due to
> >    terminology confusion).  Symbols are interned in packages--packages
> >    do not form encapsulation for code.  They exist to prevent symbol
> >    namespace clashes.
> 
> I am a little bit confused: if you bundle (assemble, collect - what's
> the word?) symbols into packages, this also separates (at least in some
> sense) their definitions.
> 
> I know that packages don't provide encapsulation in the sense of access
> rights, but I haven't claimed that.
> 
> What am I missing?

You can have two different symbols in two different packages that have the
same definition, e.g.:

(defun foo () ...)
(setf (symbol-function 'some-other-package::foo) #'foo)

So segregation of symbols and segregation of definitions are, at least in
theory, entirely orthogonal to one another.

As a practical matter, however, packages are often used to segregate
definitions, so you will not be leading beginners too seriously astray if
you tell them that's what they are for.  However, if you tell them this
you should include a disclaimer that this is not the whole truth so that
later when they learn the whole awful truth ;-) they don't get too
confused.

E.
From: Pascal Costanza
Subject: Re: My guide to Lisp
Date: 
Message-ID: <3D69FD78.76A4A3D3@cs.uni-bonn.de>
Erann Gat wrote:
> 
> In article <·················@cs.uni-bonn.de>, ········@web.de wrote:

> As a practical matter, however, packages are often used to segregate
> definitions, so you will not be leading beginners too seriously astray if
> you tell them that's what they are for.  However, if you tell them this
> you should include a disclaimer that this is not the whole truth so that
> later when they learn the whole awful truth ;-) they don't get too
> confused.

So what are packages are used for in practice beyond separation of
definitions? Can you give a few examples?

Thanks,
Pascal

--
Pascal Costanza               University of Bonn
···············@web.de        Institute of Computer Science III
http://www.pascalcostanza.de  R�merstr. 164, D-53117 Bonn (Germany)
From: Tim Bradshaw
Subject: Re: My guide to Lisp
Date: 
Message-ID: <ey3fzx1ubse.fsf@cley.com>
* Pascal Costanza wrote:
> So what are packages are used for in practice beyond separation of
> definitions? Can you give a few examples?

I use packages as a way of validating input.  You read a form with
*package* bound suitably (and `safe' reader bindings), and then walk
over the result, checking that there are only good types, and that all
symbols are external in a suitable package.  After you've done this,
you clean the package by removing any interned, non-exported symbols.
Once you are done, then you know that the input is OK (well, you are
*fairly* sure).

I suppose you might argue that this is just a way of separating
definitions, but the forms we are reading are generally not Lisp as
such.  In fact, half the time what we are doing is parsing XML with
expat, and then translating this to suitable forms, so we never go
through the reader at all.

--tim
From: Erann Gat
Subject: Re: My guide to Lisp
Date: 
Message-ID: <gat-2608021233360001@k-137-79-50-101.jpl.nasa.gov>
In article <·················@cs.uni-bonn.de>, ········@web.de wrote:

> Erann Gat wrote:
> > 
> > In article <·················@cs.uni-bonn.de>, ········@web.de wrote:
> 
> > As a practical matter, however, packages are often used to segregate
> > definitions, so you will not be leading beginners too seriously astray if
> > you tell them that's what they are for.  However, if you tell them this
> > you should include a disclaimer that this is not the whole truth so that
> > later when they learn the whole awful truth ;-) they don't get too
> > confused.
> 
> So what are packages are used for in practice beyond separation of
> definitions? Can you give a few examples?

There was a *very* long discussion of this here last March.  It starts with:

http://groups.google.com/groups?selm=gat-1603020931270001%40192.168.1.50

Bottom line: packages are used to separate *symbols*, not definitions. 
Symbols have definitions, so by separating the symbols you also separate
their definitions as a consequence, but symbols can be useful independent
of their definitions (for example, when doing symbolic programming), and
occasionally need to be separated for that purpose.  The canonical example
(actually, the only example that I know of) is if you are using two
independently-written software libraries that both return symbolic results
that use symbols with the same name and you need to keep track of whether
the result is 'library1:result or 'library2:result.

E.
From: Thomas F. Burdick
Subject: Re: My guide to Lisp
Date: 
Message-ID: <xcv3ct5pep0.fsf@conquest.OCF.Berkeley.EDU>
Pascal Costanza <········@cs.uni-bonn.de> writes:

> Matthew Danish wrote:
>
> > *  ``allows for manipulation of class hierarchies and message dispatch
> >    at run-time.''
> > 
> >    Do you mean "method" instead of "message", here?
> 
> I have learned the following terminology: messages are sent to objects,
> and message dispatch consists of selecting the appropriate method for
> this specific object. So you send and dispatch messages, and methods get
> executed.
> 
> Is the terminology different in CLOS?

Yes.  You call a generic function.  It looks at the types of its
arguments, computes the effective method, and calls that.  The main
important difference for people new to the language is that messages
aren't sent to objects, generic functions are passed objects; and
methods are methods *on* generic functions, not *in* classes.

> > *  Packages
> > 
> >    Packages are not for bundling definitions but for containing symbols.
> >    This is a significant distinction between the CL package system and a
> >    code module system that many people often miss (probably due to
> >    terminology confusion).  Symbols are interned in packages--packages
> >    do not form encapsulation for code.  They exist to prevent symbol
> >    namespace clashes.
> 
> I am a little bit confused: if you bundle (assemble, collect - what's
> the word?) symbols into packages, this also separates (at least in some
> sense) their definitions.
> 
> I know that packages don't provide encapsulation in the sense of access
> rights, but I haven't claimed that.
> 
> What am I missing?

A variety of more subtle, potentially confusing uses of packages.  For
newbies, I think your summary was fine, although possibly it would be
good to tell them that it's a more general-purpose facility that is
normally just used to bundle definitions.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: Nicolas Neuss
Subject: Re: My guide to Lisp
Date: 
Message-ID: <874rdixapy.fsf@ortler.iwr.uni-heidelberg.de>
Pascal Costanza <········@cs.uni-bonn.de> writes:

> > *  ``CLISP, obviously almost all platforms''
> > 
> >   It's only obvious after you click the link and read a little about it,
> >   though.
> 
> This was a translation error. I have changed it to "apparently". The
> German language uses one and the same word for both "apparently" and
> "obviously" (and also "seemingly", "evidently", and so on)!

Sorry, but this is nonsense: "obviously" is in German "offensichtlich"
and "apparently" is in German "scheinbar" or "anscheinend".

Nicolas.
From: Pascal Costanza
Subject: Re: My guide to Lisp
Date: 
Message-ID: <3D69FEBB.45737FC@cs.uni-bonn.de>
Nicolas Neuss wrote:
> 
> Pascal Costanza <········@cs.uni-bonn.de> writes:
> 
> > > *  ``CLISP, obviously almost all platforms''
> > >
> > >   It's only obvious after you click the link and read a little about it,
> > >   though.
> >
> > This was a translation error. I have changed it to "apparently". The
> > German language uses one and the same word for both "apparently" and
> > "obviously" (and also "seemingly", "evidently", and so on)!
> 
> Sorry, but this is nonsense: "obviously" is in German "offensichtlich"
> and "apparently" is in German "scheinbar" or "anscheinend".

See http://makeashorterlink.com/?N28A16C91

Pascal

--
Pascal Costanza               University of Bonn
···············@web.de        Institute of Computer Science III
http://www.pascalcostanza.de  R�merstr. 164, D-53117 Bonn (Germany)
From: Nicolas Neuss
Subject: Re: My guide to Lisp
Date: 
Message-ID: <87y9atx6e9.fsf@ortler.iwr.uni-heidelberg.de>
Pascal Costanza <········@cs.uni-bonn.de> writes:

> Nicolas Neuss wrote:
> > 
> > Pascal Costanza <········@cs.uni-bonn.de> writes:
> > 
> > > > *  ``CLISP, obviously almost all platforms''
> > > >
> > > >   It's only obvious after you click the link and read a little about it,
> > > >   though.
> > >
> > > This was a translation error. I have changed it to "apparently". The
> > > German language uses one and the same word for both "apparently" and
> > > "obviously" (and also "seemingly", "evidently", and so on)!
> > 
> > Sorry, but this is nonsense: "obviously" is in German "offensichtlich"
> > and "apparently" is in German "scheinbar" or "anscheinend".
> 
> See http://makeashorterlink.com/?N28A16C91
> 
> Pascal

Yes, this is exactly what I meant.  You wanted to say "offensichtlich"
(i.e. "apparent" in the meaning of "obviously") at the beginning.
Therefore, the problem does not lie with the German language but with
you.

Nicolas.
From: Nils Goesche
Subject: Re: My guide to Lisp
Date: 
Message-ID: <lky9atix7v.fsf@pc022.bln.elmeg.de>
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:

> Pascal Costanza <········@cs.uni-bonn.de> writes:
> 
> > Nicolas Neuss wrote:
> > > 
> > > Pascal Costanza <········@cs.uni-bonn.de> writes:
> > > 
> > > > > *  ``CLISP, obviously almost all platforms''
> > > > >
> > > > >   It's only obvious after you click the link and read a little about it,
> > > > >   though.
> > > >
> > > > This was a translation error. I have changed it to "apparently". The
> > > > German language uses one and the same word for both "apparently" and
> > > > "obviously" (and also "seemingly", "evidently", and so on)!
> > > 
> > > Sorry, but this is nonsense: "obviously" is in German "offensichtlich"
> > > and "apparently" is in German "scheinbar" or "anscheinend".
> > 
> > See http://makeashorterlink.com/?N28A16C91
> > 
> > Pascal
> 
> Yes, this is exactly what I meant.  You wanted to say "offensichtlich"
> (i.e. "apparent" in the meaning of "obviously") at the beginning.
> Therefore, the problem does not lie with the German language but with
> you.

Maybe he wanted to say `offenbar'.

Regards,
-- 
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."

PGP key ID 0x0655CFA0
From: Aleksandr Skobelev
Subject: Re: My guide to Lisp
Date: 
Message-ID: <m3ptwa59s5.fsf@list.ru>
Pascal Costanza <········@cs.uni-bonn.de> writes:

> Hi everybody,
> 
> I am relatively new to the Lisp world. Because of my involvement with
> Richard Gabriel's Feyerabend project I have been confronted with Common
> Lisp and digged deeply into it for the last few months. I have written a
> summary of what I have found out and made it available recently at
> http://www.pascalcostanza.de/lisp/guide.html. Please let me know what
> you think.
> 


It seems to me as a very good intoductional material.  But you've missed
CMUCL (http://www.cons.org/cmucl/) in the list of available
implementations. 
From: Pascal Costanza
Subject: Re: My guide to Lisp
Date: 
Message-ID: <3D6631AC.4890715A@cs.uni-bonn.de>
Pascal Costanza wrote:
> 

> http://www.pascalcostanza.de/lisp/guide.html. Please let me know what
> you think.

...thanks a lot to the many comments. I will include them in a new
version. (Soon!)

All the best,
Pascal

--
Pascal Costanza               University of Bonn
···············@web.de        Institute of Computer Science III
http://www.pascalcostanza.de  R�merstr. 164, D-53117 Bonn (Germany)
From: Thomas Stegen CES2000
Subject: Re: My guide to Lisp
Date: 
Message-ID: <3d66325f@nntphost.cis.strath.ac.uk>
"Pascal Costanza" <········@cs.uni-bonn.de> wrote in message
······················@cs.uni-bonn.de...
> Hi everybody,
>
> I am relatively new to the Lisp world. Because of my involvement with
> Richard Gabriel's Feyerabend project I have been confronted with Common
> Lisp and digged deeply into it for the last few months. I have written a
> summary of what I have found out and made it available recently at
> http://www.pascalcostanza.de/lisp/guide.html. Please let me know what
> you think.
>
> All the best,
> Pascal


Good stuff.

A comment though.

Under '4. Some first obstacles'

You mention special forms and say that macros are special forms.
They are not.

This link to the hyperspec should provide the details:
http://www.lispworks.com/reference/HyperSpec/Body/03_abab.htm


--
Thomas.

Approaching singularity.
From: Christopher Browne
Subject: Re: My guide to Lisp
Date: 
Message-ID: <ak5thv$1fsi9m$1@ID-125932.news.dfncis.de>
A long time ago, in a galaxy far, far away, Pascal Costanza <········@cs.uni-bonn.de> wrote:
> I am relatively new to the Lisp world. Because of my involvement with
> Richard Gabriel's Feyerabend project I have been confronted with Common
> Lisp and digged deeply into it for the last few months. I have written a
> summary of what I have found out and made it available recently at
> http://www.pascalcostanza.de/lisp/guide.html. Please let me know what
> you think.

That's one of the best brief comparative discussions that I've seen.

The "hygenic" discussion should probably be cognizant of the fact that
people at both ends of the spectrum (pro- and con-) tend to get
hysterical about the _other_ end at the very mention of the existence
of both sides.  It's probably worth mentioning something to the effect
that it's highly political.

The discussion of LOOP should mention that the LOOP facility
represents a pretty sophisticated "sublanguage" that has been created
using macros.  It is complex enough that understanding it _completely_
is not usually likely to happen.  But on the other hand, its intent is
to cut down on the need to build complex "hives" of inter-nested
control structures.  A single LOOP can often replace the combination
of a LET, DO, with a couple CONDs and PROGNs thrown in for good
measure.  It adds some complexity (it's not easy to understand), but
buys you a diminishment of other complexity (typically chopping out
_several_ other control structures).

There should be _some_ mention of reader macros, which are pretty much
unique to Lisp.

In Lisp, reader macros are part of the 'base language,'
http://www.cs.utsa.edu/research/AI/cltl/clm/node188.html, allowing you
to integrate extensions in, and, if you define your own custom
*READTABLE*, allowing you to build your own language parser.  In
practice, it is usually used to provide relatively minor extensions.
In _theory_, you could probably write a C++ compiler using reader
macros, although this would likely be a sufficiently awkward task as
to turn everyone off the project.  (I suspect that the Symbolics C
compiler may have been constructed this way; I'm not sure.)

Other languages tend to support doing parsing via some external parser
generator, with yacc (used with C) being pretty characteristic of the
usual approach, of

 -> Special language for describing the syntax of the language to be
    parsed; 
 -> Special compiler that parses that language, and generates C code
    reading that syntax, where "actions" are indicated by snippets of
    code dropped into the parser reader.

(Tools VERY much analagous to yacc are available where the "actions"
represent code in C++, Perl, Python, Java, and OCAML.)
-- 
(reverse (concatenate 'string ········@" "enworbbc"))
http://cbbrowne.com/info/
Microsoft spel chekar vor sail, worgs grate !!
-- <·······@inf.fu-berlin.de>, Felix von Leitner
From: Erik Naggum
Subject: Re: My guide to Lisp
Date: 
Message-ID: <3239145670302676@naggum.no>
* Christopher Browne
| In Lisp, reader macros are part of the 'base language,'
| http://www.cs.utsa.edu/research/AI/cltl/clm/node188.html, allowing you to
| integrate extensions in, and, if you define your own custom *READTABLE*,
| allowing you to build your own language parser.

  I think it is important to be aware that the syntax of Common Lisp is
  programmable and that the value of `*readtable*� is not just some
  potentially extended syntax, it /is/ the syntax in which code is read.
  There is in fact no way to get around reader macros.  ( invokes a reader
  macro.

| In practice, it is usually used to provide relatively minor extensions.

  No, it is used to define the syntax of Common Lisp.

-- 
Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
From: Christopher Browne
Subject: Re: My guide to Lisp
Date: 
Message-ID: <ak70ol$1g4d9i$2@ID-125932.news.dfncis.de>
Centuries ago, Nostradamus foresaw when Erik Naggum <····@naggum.no> would write:
> * Christopher Browne
> | In Lisp, reader macros are part of the 'base language,'
> | http://www.cs.utsa.edu/research/AI/cltl/clm/node188.html, allowing you to
> | integrate extensions in, and, if you define your own custom *READTABLE*,
> | allowing you to build your own language parser.
>
>   I think it is important to be aware that the syntax of Common Lisp is
>   programmable and that the value of `*readtable*� is not just some
>   potentially extended syntax, it /is/ the syntax in which code is read.
>   There is in fact no way to get around reader macros.  ( invokes a reader
>   macro.
>
> | In practice, it is usually used to provide relatively minor extensions.
>
>   No, it is used to define the syntax of Common Lisp.

Well, there _is_ that.

But the things I was getting at were that:
 a) It's _fairly_ typical for reader macros to be used to extend CL
    syntax, as opposed to creating completely different things from
    scratch,  and
 b) It seems most typical for the languages created as a result to be
    "basically Lisp."  In comparison with yacc-based things, that are
    often rather different even from C, on which they are commonly
    based.

And to be sure, the point was that the syntax of CL is programmable,
and that, unlike with other languages, where you need completely
separate tools similar to yacc to create new syntax from scratch,
reader macros are there to be used when neede.
-- 
(concatenate 'string "cbbrowne" ·@acm.org")
http://www.ntlug.org/~cbbrowne/linuxxian.html
"Although  Unix is  more reliable,  NT may  become more  reliable with
time"  --   Ron  Redman,  deputy  technical  director   of  the  Fleet
Introduction Division of the Aegis Program Executive Office, US Navy.
From: Ray Blaak
Subject: Yacc Attack (was Re: My guide to Lisp)
Date: 
Message-ID: <u8z2w650f.fsf_-_@telus.net>
Christopher Browne <········@acm.org> writes:
> Other languages tend to support doing parsing via some external parser
> generator, with yacc (used with C) being pretty characteristic of the
> usual approach, of
> 
>  -> Special language for describing the syntax of the language to be
>     parsed; 
>  -> Special compiler that parses that language, and generates C code
>     reading that syntax, where "actions" are indicated by snippets of
>     code dropped into the parser reader.

After having used Yacc and Yacc-like tools for a number of years, I have come
to the conclusion that Yacc sucks.

Yes one can set up the grammar files to readily describe your language, but
the problem is with actually implementing the grammar rules. The complexity
involved tends to outweigh the supposed simplicity of using Yacc in the first
place.

These days I write everything directly in source code. With the appropriate
recursive descent techniques, proper naming and abstractions, the
implementation of a language parser in your favourite language (CL over
*here*, of course) is just as nearly succinct as writing it in a specialized
grammar file.

You also then have the added benefit complete flexibility of being able to do
unusual things when you need to (e.g. I need n-token lookahead for this rule
-- I'll just implement it now; hmm, I need to do raw unicode escape sequence
processing across *all* tokenization, with special case handing if I happen to
be in a string literal...).

Finally, everything is self contained: no dependencies on 3rd party tools that
may or may not work well in your environment (got to hack Yacc to do C++
instead of C; need an Ada version of Yacc; I was using Visual Parse -- great
tool -- but it's now 5 PCs later, and does my license still work; etc., etc.).

--
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
·····@telus.net                                The Rhythm has my soul.
From: Christopher Browne
Subject: Re: Yacc Attack (was Re: My guide to Lisp)
Date: 
Message-ID: <ak8mkc$1g44l6$1@ID-125932.news.dfncis.de>
Centuries ago, Nostradamus foresaw when Ray Blaak <·····@telus.net> would write:
> Christopher Browne <········@acm.org> writes:
>> Other languages tend to support doing parsing via some external parser
>> generator, with yacc (used with C) being pretty characteristic of the
>> usual approach, of
>> 
>>  -> Special language for describing the syntax of the language to be
>>     parsed; 
>>  -> Special compiler that parses that language, and generates C code
>>     reading that syntax, where "actions" are indicated by snippets of
>>     code dropped into the parser reader.
>
> After having used Yacc and Yacc-like tools for a number of years, I
> have come to the conclusion that Yacc sucks.
>
> Yes one can set up the grammar files to readily describe your
> language, but the problem is with actually implementing the grammar
> rules. The complexity involved tends to outweigh the supposed
> simplicity of using Yacc in the first place.

I recently had opportunity to "toy" with it a bit.  I thought yacc
wasn't too bad, by itself.  And lex wasn't too bad, either.
Unfortunately, the complexity that pops in when you combine them sucks
pretty badly.

My sense is, nonetheless, that a whopping lot of the C-based projects
wind up with people heading off to flakey libraries or flakey "stuff
written in the source code" because they were too fraidy-cat to
_consider_ lex/yacc.  

You can more than likely characterize a simple config file parser in a
dozen lines of lex.  Add configuration to a Makefile, and that
probably bloats to 50 lines of code.  It's pretty easy for there to be
many times that much code introduced when you pull in an XML parser or
something of the sort.

I'm not disagreeing with the Lisp side of things; the point is that if
you've "made your bed" with C, the parser generators _are_ pretty good
in comparison with the C-based alternatives, even if they are rather
less flexible than what CL provides as part of the language.
-- 
(concatenate 'string "cbbrowne" ·@cbbrowne.com")
http://www.ntlug.org/~cbbrowne/nonrdbms.html
"Armenians   and   Azerbaijanis  in   Stepanakert,   capital  of   the
Nagorno-Karabakh autonomous  region, rioted over  much needed spelling
reform in the Soviet Union."  -- Rolling Stone's '88 Year in Review
From: Ray Blaak
Subject: Re: Yacc Attack (was Re: My guide to Lisp)
Date: 
Message-ID: <uhehjihtp.fsf@telus.net>
Christopher Browne <········@acm.org> writes:
> I'm not disagreeing with the Lisp side of things; the point is that if
> you've "made your bed" with C, the parser generators _are_ pretty good
> in comparison with the C-based alternatives, even if they are rather
> less flexible than what CL provides as part of the language.

Certainly Yacc fits the best with C, and thus one gets the most benefit there.

But my comment is really pan-language: structure your parsing code properly,
and one can nearly achieve the succinctness and clarity of a grammar file,
with the benefit of improved flexibility and ease of maintenance.

Ray
From: Petter Gustad
Subject: Re: Yacc Attack (was Re: My guide to Lisp)
Date: 
Message-ID: <87ptw7cj4m.fsf@filestore.home.gustad.com>
Ray Blaak <·····@telus.net> writes:
> After having used Yacc and Yacc-like tools for a number of years, I have come
> to the conclusion that Yacc sucks.

I have to agree with you. However, I've done some parsers using PCCTS
and found the grammers and code easy to maintain. I just wish it could
produce CL(OS) output. Is there such a port of PCCTS or ANTLR
available?

Petter
-- 
________________________________________________________________________
Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com
From: Paul F. Dietz
Subject: Re: Yacc Attack (was Re: My guide to Lisp)
Date: 
Message-ID: <3D68C734.F1844015@dls.net>
Petter Gustad wrote:

> I have to agree with you. However, I've done some parsers using PCCTS
> and found the grammers and code easy to maintain. I just wish it could
> produce CL(OS) output. Is there such a port of PCCTS or ANTLR
> available?

I have very much wanted something like that.  I think I'd be willing
to pay something for it, too.

	Paul
From: Christopher Browne
Subject: Re: Yacc Attack (was Re: My guide to Lisp)
Date: 
Message-ID: <ake3og$1hfa94$2@ID-125932.news.dfncis.de>
In an attempt to throw the authorities off his trail, "Paul F. Dietz" <·····@dls.net> transmitted:
> Petter Gustad wrote:
>
>> I have to agree with you. However, I've done some parsers using PCCTS
>> and found the grammers and code easy to maintain. I just wish it could
>> produce CL(OS) output. Is there such a port of PCCTS or ANTLR
>> available?
>
> I have very much wanted something like that.  I think I'd be willing
> to pay something for it, too.

.. But the fairly minscule market makes it all the _less_ likely that
someone would consider such a thing commercially viable than is true
for the existing parsers, very few of which are sold as commercial
products...
-- 
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://www3.sympatico.ca/cbbrowne/sap.html
cc hello.c, in Canada, results in:
  eh.oot
From: Ray Blaak
Subject: Re: Yacc Attack (was Re: My guide to Lisp)
Date: 
Message-ID: <uhehif4k5.fsf@telus.net>
Petter Gustad <·············@gustad.com> writes:
> Ray Blaak <·····@telus.net> writes:
> > After having used Yacc and Yacc-like tools for a number of years, I have
> > come to the conclusion that Yacc sucks.
> 
> I have to agree with you. However, I've done some parsers using PCCTS
> and found the grammers and code easy to maintain. I just wish it could
> produce CL(OS) output. Is there such a port of PCCTS or ANTLR
> available?

Sorry, I don't know. But aren't those tools configurable (or is ANTLR)? I seem
to recall some tool being configurable with the appropriate "language" file.

--
Cheers,                                        The Rhythm is around me,
                                               The Rhythm has control.
Ray Blaak                                      The Rhythm is inside me,
·····@telus.net                                The Rhythm has my soul.
From: Petter Gustad
Subject: Re: Yacc Attack (was Re: My guide to Lisp)
Date: 
Message-ID: <87it1xv3r1.fsf@filestore.home.gustad.com>
Ray Blaak <·····@telus.net> writes:

> Petter Gustad <·············@gustad.com> writes:
> > Ray Blaak <·····@telus.net> writes:
> > > After having used Yacc and Yacc-like tools for a number of years, I have
> > > come to the conclusion that Yacc sucks.
> > 
> > I have to agree with you. However, I've done some parsers using PCCTS
> > and found the grammers and code easy to maintain. I just wish it could
> > produce CL(OS) output. Is there such a port of PCCTS or ANTLR
> > available?
> 
> Sorry, I don't know. But aren't those tools configurable (or is ANTLR)? I seem
> to recall some tool being configurable with the appropriate "language" file.

You can build a parser for any language by specifying a grammar file.
However, the output from ANTRL is C/C++, Java, or Sather. 

Petter
-- 
________________________________________________________________________
Petter Gustad   8'h2B | (~8'h2B) - Hamlet in Verilog   http://gustad.com
From: Robert Braddock
Subject: Re: Yacc Attack (was Re: My guide to Lisp)
Date: 
Message-ID: <e79a05a4.0208272026.7f02872e@posting.google.com>
Petter Gustad <·············@gustad.com> wrote in message news:<··············@filestore.home.gustad.com>...
> I have to agree with you. However, I've done some parsers using PCCTS
> and found the grammers and code easy to maintain. I just wish it could
> produce CL(OS) output. Is there such a port of PCCTS or ANTLR

Thanks for the pointer--I've been looking to work on something like
this. I'm currently unemployed, so I have some free time to look into
these. If you'd like to make any suggestions about what the lisp
results ought to be like, please do. [I'm early on in learning lisp,
and will certainly need external help at the polishing/optimizing
stage.]

--
Robert Braddock
From: Dorai Sitaram
Subject: Re: My guide to Lisp
Date: 
Message-ID: <ak60vr$rlh$1@news.gte.com>
In article <·················@cs.uni-bonn.de>,
Pascal Costanza  <········@web.de> wrote:
>
>I am relatively new to the Lisp world. Because of my involvement with
>Richard Gabriel's Feyerabend project I have been confronted with Common
>Lisp and digged deeply into it for the last few months. I have written a
>summary of what I have found out and made it available recently at
>http://www.pascalcostanza.de/lisp/guide.html. Please let me know what
>you think.

OK, I will mention things that hopefully others haven't
covered also.

I think your essay acquires an unnecessary emphasis and
credibility problem when you bring in Scheme like
you do.

You spend a tremendous amount of time on Scheme, and
one would have expected a serious critique, but you
give the impression that all you want to do is say
something negative about Scheme in a hit-and-run way
without the necessity of having to back it up.  Some
sentences like "What I don't like about Scheme is that
it is a "right-thing" language that has strong notions
about how things should be done" are out-of-place in a
presumably thoughtful essay, even in an "opinionated"
one.  Languages don't have notions, let alone strong
notions, do they?  Besides, is any programming
language, even Perl, free from the chore of having to
fix what its language expressions should mean?  (What
is funny is that when users have to come to terms with
Common Lisp's own "right-thing" of doing things,
you suggest, on more than one occasion, that they
should stick it out and "get used to it".)

More than once you say that Common Lisp is a practical
language with pragmatic concerns, especially in
contrast to Scheme.  Add some corroborating evidence
for that.  (Just insisting that Scheme is
impractical won't help those among your readers who
want to know about Common Lisp for its own sake, not as
a Scheme substitute.) There is nothing in your essay
that suggests that the reader should believe that
Common Lisp is anything but a low-profile boutique
language, if that.  I should think that supporting
evidence in this regard is of supreme importance in an
essay of this type.  You must certainly have enough
space for detailing why Common Lisp is A Mighty
Practical Force, if you had enough space to dis Scheme.  

In general, your bringing up the dichotomy where Scheme
is about aesthetics and Common Lisp is about
pragmatism, although it may play well to yellow-dog
Common Lisp fans (who clearly don't need a "guide"), is
tired and muddled.  In the Lisp-1/Lisp-2 paragraph, for
instance, (a) you first say that the difference has no
practical implications, (b) then you say that Common
Lisp's choice in the matter is the more practical one,
(c) then you say that you don't really know the
details, and (d) finally you say that you don't really
care.  Why not simply _not_ talk about things you
apparently don't have the will to talk about cogently?
At the very least, this will let you focus on the areas
where you really do have a strong opinion that you can
express forcefully and persuasively.  And by opinion I
don't mean a vague or tribal bias that you can't be
bothered to go into, but something you really
have seriously thought about. 

I would suggest cutting out all references to Scheme
and concentrating on Common Lisp.  Your interest is in
Common Lisp now, so run with it.  

HTH.
From: Pascal Costanza
Subject: Re: My guide to Lisp
Date: 
Message-ID: <3D6A1BB9.351E1FDA@cs.uni-bonn.de>
Dorai Sitaram wrote:
> 
> In article <·················@cs.uni-bonn.de>,
> Pascal Costanza  <········@web.de> wrote:

> >http://www.pascalcostanza.de/lisp/guide.html. Please let me know what
> >you think.
> 
> OK, I will mention things that hopefully others haven't
> covered also.
> 
> I think your essay acquires an unnecessary emphasis and
> credibility problem when you bring in Scheme like
> you do.
> 
> You spend a tremendous amount of time on Scheme, and
> one would have expected a serious critique, but you
> give the impression that all you want to do is say
> something negative about Scheme in a hit-and-run way
> without the necessity of having to back it up.

No, I don't want to say anything negative about Scheme. I have seriously
considered using Scheme but I have found that Common Lisp better suits
my needs. That's all.

> Some
> sentences like "What I don't like about Scheme is that
> it is a "right-thing" language that has strong notions
> about how things should be done" are out-of-place in a
> presumably thoughtful essay, even in an "opinionated"
> one.

My impression is that the Scheme designers have notions about how things
should be done "correctly" and I also have the impression that Common
Lisp gives the programmer more freedom. Compared to other languages from
other language families both Scheme and Common Lisp offer a tremendous
amount of flexibility. If Common Lips weren't available I would have
chosen Scheme. (...and Common Lispers should be happy when a Lisp newbie
chooses Scheme and the other way around. This is better than not taking
a look at Lisp at all.)

> Languages don't have notions, let alone strong
> notions, do they?

Yes they do, in the sense that they reflect the notions of their
designers.

> Besides, is any programming
> language, even Perl, free from the chore of having to
> fix what its language expressions should mean?

No, there are no absolutes. Freedom and flexibility can only be measured
relatively when you compare several languages with each other.
Furthermore, it always depends on your concrete requirements.

> (What
> is funny is that when users have to come to terms with
> Common Lisp's own "right-thing" of doing things,
> you suggest, on more than one occasion, that they
> should stick it out and "get used to it".)
> More than once you say that Common Lisp is a practical
> language with pragmatic concerns, especially in
> contrast to Scheme.  Add some corroborating evidence
> for that.  (Just insisting that Scheme is
> impractical won't help those among your readers who
> want to know about Common Lisp for its own sake, not as
> a Scheme substitute.) There is nothing in your essay
> that suggests that the reader should believe that
> Common Lisp is anything but a low-profile boutique
> language, if that.

I don't understand the term "low-profile boutique language" - what do
you mean by this? (This is a serious question - I am not a native
speaker.)

> I should think that supporting
> evidence in this regard is of supreme importance in an
> essay of this type.  You must certainly have enough
> space for detailing why Common Lisp is A Mighty
> Practical Force, if you had enough space to dis Scheme.

I don't think that I say overly negative things about Scheme.

> In general, your bringing up the dichotomy where Scheme
> is about aesthetics and Common Lisp is about
> pragmatism, although it may play well to yellow-dog
> Common Lisp fans (who clearly don't need a "guide"), is
> tired and muddled.

If you read the history about Scheme you can notice that the designers
(Sussman and Steele) aimed at minimality, orthogonality and
generalization. These are primarily aesthetic principles derived from
the world of mathematics. I don't think that aesthetics have a lower
value per se than pragmatics or the other way around, so I don't see in
which sense my guide can be read as a negative criticism of Scheme.
Sure, I have opted for Common Lisp because it has more value for what I
want to do and the text clearly shows my excitement. (I am not willing
to do anything about the latter. ;)

By the way, I don't see computer science primarily as a mathematical or
natural science.

> In the Lisp-1/Lisp-2 paragraph, for
> instance, (a) you first say that the difference has no
> practical implications,

It has no practical implications, because obviously you can write real
programs in both languages. They both offer means to deal with the
consequences of being either Lisp-1 or Lisp-2.

> (b) then you say that Common
> Lisp's choice in the matter is the more practical one,

This is what I derive from Richard Gabriel's and Kent Pitman's article
about this issue. Furthermore, it is more practical because it reduces
the need for hygiene in Common Lisp. Hygiene is an example of
generalizing lexical closures in a sense - again, this is an aesthetic
quality and a safety measure but doesn't give you more expressive power.
To the contrary, it deliberately restricts expressive power because
aesthetics and safety have a higher priority in Scheme. Again, this is
not a bad thing per se, but I personally would like to use a language
that, when in doubt, prioritizes expressive power. This makes me more
confident that I can always do the things I want to do. This is what I
mean by pragmatics.

Of course, your mileage may vary and your requirements may be different.
This is fine by me, and I don't have any strong feelings about that.

> (c) then you say that you don't really know the
> details, and (d) finally you say that you don't really
> care.

I have skipped over Richard Gabriel's and Kent Pitman's article about
this issue and have concluded that they provide many, many details that
I am not interested in for the time being. From what I have read about
the consequences of Common Lisp being a Lisp-2 I  have concluded that I
can live with them.

> Why not simply _not_ talk about things you
> apparently don't have the will to talk about cogently?
> At the very least, this will let you focus on the areas
> where you really do have a strong opinion that you can
> express forcefully and persuasively.  And by opinion I
> don't mean a vague or tribal bias that you can't be
> bothered to go into, but something you really
> have seriously thought about.
> 
> I would suggest cutting out all references to Scheme
> and concentrating on Common Lisp.  Your interest is in
> Common Lisp now, so run with it.

No, I don't think I can do that. The guide is meant for people who come
from a non-Lisp background and try to take a closer look at Lisp. When
you do that you quickly find statements about Scheme and Common Lisp
being the two "serious" Lisps today, and you can find strong statements
from both camps about the respective advantages. Therefore, you have to
look closely at these two languages in order to make up your mind. I
have put some effort into studying the merits of both languages and it
has taken some time in order to understand the advantages and
disadvantages of both. None of them is clearly the better choice. For
example, Scheme has continuations and Common Lisp misses them. So Scheme
is clearly the better choice if you would like to experiment with
continuations.

One of the things that I want to achieve with the guide is to reassure
people who have opted for Common Lisp that this is a reasonable choice.
It is also a reasonable choice to opt for Scheme, and I think I have
stated this clearly in the guide. I have to mention both languages in
order to state these things. If I wouldn't mention Scheme some readers
might still be unsure about having made the "right" choice.

Among the things I can consider for a later version are the following.
1) I can draw a better line between what statements are relevant before
the reader has opted for Common Lisp or for Scheme and what are
essentially relevant for Common Lisp only. 2) A similar guide could be
added for people who choose Scheme.

It's too early for me to do 1). It's very unlikey that I will do 2)
because I don't expect to gain sufficient hands-on knowledge about
Scheme. However, I am happy to include links to similar introductions to
the Scheme world.

Pascal

--
Pascal Costanza               University of Bonn
···············@web.de        Institute of Computer Science III
http://www.pascalcostanza.de  R�merstr. 164, D-53117 Bonn (Germany)
From: Christopher Browne
Subject: Re: My guide to Lisp
Date: 
Message-ID: <akdf17$1hm2dn$1@ID-125932.news.dfncis.de>
Quoth Pascal Costanza <········@cs.uni-bonn.de>:
> Dorai Sitaram wrote:
>> In the Lisp-1/Lisp-2 paragraph, for instance, (a) you first say
>> that the difference has no practical implications,

> It has no practical implications, because obviously you can write
> real programs in both languages. They both offer means to deal with
> the consequences of being either Lisp-1 or Lisp-2.

Unfortunately, this is a _very_ controversial area, and if you
describe things vaguely, which you have, that amounts to saying things
_very badly_.

The above paragraph that you wrote is a pretty _good_ one, in that it
seems to describe reasonably accurately what you perceive as the "lack
of practical importance" of the issue.  You should almost certainly
replace the "vague talk of no practical implications" with

   It has no practical implications, because obviously you can write
   real programs in both languages. They both offer means to deal with
   the consequences of being either Lisp-1 or Lisp-2.

That still won't be totally accurate, in general; it is quite clear
that people that are fanatics in both camps _really care_ about the
practical implications of the differences.  Almost certainly they are
seeing things, out of years of experience, that you can't yet see.

I realistically think this is a battle you might just as well not get
yourself into.  There are lots of sharp point edges around, and as a
relative novice, you're liable to get yourself cut up pretty badly.

>> (b) then you say that Common Lisp's choice in the matter is the
>> more practical one,
>
> This is what I derive from Richard Gabriel's and Kent Pitman's
> article about this issue. Furthermore, it is more practical because
> it reduces the need for hygiene in Common Lisp. Hygiene is an
> example of generalizing lexical closures in a sense - again, this is
> an aesthetic quality and a safety measure but doesn't give you more
> expressive power.  To the contrary, it deliberately restricts
> expressive power because aesthetics and safety have a higher
> priority in Scheme. Again, this is not a bad thing per se, but I
> personally would like to use a language that, when in doubt,
> prioritizes expressive power. This makes me more confident that I
> can always do the things I want to do. This is what I mean by
> pragmatics.
>
> Of course, your mileage may vary and your requirements may be
> different.  This is fine by me, and I don't have any strong feelings
> about that.

My sense is that you're too new to Lisp for these to _truly_ be
important issues to you.

We recently had a would-be-newcomer getting all excited about the vast
and horrible problems with DEFSTRUCT, feeling quite prepared to "mark
Common Lisp down" because the problems with DEFSTRUCT were _so_
crucial.  He was too busy fighting over this one tiny area to move on
and learn about other data structures that might well relieve the
problems he _thought_ he was facing.

I don't think you can provide compelling arguments about this sort of
thing until you have the experience to be regarded as an "old salt"
like Richard Gabriel or Kent Pitman.  They have probably _forgotten_
more about Common Lisp (and in Kent's case, Scheme) than many of us
will ever know, and their sweeping scope of knowledge means that we're
inclined to at least _listen_ to them because they aren't so liable to
fall into the "there's a horrible problem in this one little corner;
LISP IS USELESS!!!  LISP IS USELESS!!!" trap.

>> Why not simply _not_ talk about things you apparently don't have
>> the will to talk about cogently?  At the very least, this will let
>> you focus on the areas where you really do have a strong opinion
>> that you can express forcefully and persuasively.  And by opinion I
>> don't mean a vague or tribal bias that you can't be bothered to go
>> into, but something you really have seriously thought about.
>> 
>> I would suggest cutting out all references to Scheme and
>> concentrating on Common Lisp.  Your interest is in Common Lisp now,
>> so run with it.
>
> No, I don't think I can do that. The guide is meant for people who
> come from a non-Lisp background and try to take a closer look at
> Lisp. When you do that you quickly find statements about Scheme and
> Common Lisp being the two "serious" Lisps today, and you can find
> strong statements from both camps about the respective
> advantages. Therefore, you have to look closely at these two
> languages in order to make up your mind. I have put some effort into
> studying the merits of both languages and it has taken some time in
> order to understand the advantages and disadvantages of both. None
> of them is clearly the better choice. For example, Scheme has
> continuations and Common Lisp misses them. So Scheme is clearly the
> better choice if you would like to experiment with continuations.
>
> One of the things that I want to achieve with the guide is to reassure
> people who have opted for Common Lisp that this is a reasonable choice.
> It is also a reasonable choice to opt for Scheme, and I think I have
> stated this clearly in the guide. I have to mention both languages in
> order to state these things. If I wouldn't mention Scheme some readers
> might still be unsure about having made the "right" choice.
>
> Among the things I can consider for a later version are the following.
> 1) I can draw a better line between what statements are relevant before
> the reader has opted for Common Lisp or for Scheme and what are
> essentially relevant for Common Lisp only. 2) A similar guide could be
> added for people who choose Scheme.
>
> It's too early for me to do 1). It's very unlikey that I will do 2)
> because I don't expect to gain sufficient hands-on knowledge about
> Scheme. However, I am happy to include links to similar introductions to
> the Scheme world.

But by putting yourself in this position, you are putting yourself in
a spot in between two camps of fanatics that are armed with lots of
pointy sticks.  You're likely to _by accident_ say something that
offends one side or the other /or both/, and thereby get both sides
attacking _you_.

The fact that you "mean well" doesn't matter to the fanatics.

The fact that Salmund Rushdie (sp?  It's a transliteration from
something like Arabic anyways! :-)) felt he had a lot of respect for
Islam did not prevent an assasination contract from going out on his
head.

Nobody's going to do _that_ over you doing a comparative essay on
Scheme versus Common Lisp, but you're still not going to make the
fanatics into friends out of presenting your own _Satanic Verses_.
-- 
(reverse (concatenate 'string ········@" "enworbbc"))
http://cbbrowne.com/info/multiplexor.html
``What this means is that when  people say, "The X11 folks should have
done this, done that, or included this or that", they really should be
saying "Hey, the X11 people were smart enough to allow me to add this,
that and the other myself."''  -- David B. Lewis <···@motifzone.com>
From: Pascal Costanza
Subject: Re: My guide to Lisp
Date: 
Message-ID: <3D6A4F5C.5A2F5D96@cs.uni-bonn.de>
Christopher Browne wrote:
> 
> Quoth Pascal Costanza <········@cs.uni-bonn.de>:
> > Dorai Sitaram wrote:
> >> In the Lisp-1/Lisp-2 paragraph, for instance, (a) you first say
> >> that the difference has no practical implications,
> 
> > It has no practical implications, because obviously you can write
> > real programs in both languages. They both offer means to deal with
> > the consequences of being either Lisp-1 or Lisp-2.
> 
> Unfortunately, this is a _very_ controversial area, and if you
> describe things vaguely, which you have, that amounts to saying things
> _very badly_.
> 
> The above paragraph that you wrote is a pretty _good_ one, in that it
> seems to describe reasonably accurately what you perceive as the "lack
> of practical importance" of the issue.  You should almost certainly
> replace the "vague talk of no practical implications" with
> 
>    It has no practical implications, because obviously you can write
>    real programs in both languages. They both offer means to deal with
>    the consequences of being either Lisp-1 or Lisp-2.

This is very good and constructive feedback, and I highly appreciate
that. Thanks a lot - I will probably include this in the next version.

> That still won't be totally accurate, in general; it is quite clear
> that people that are fanatics in both camps _really care_ about the
> practical implications of the differences.  Almost certainly they are
> seeing things, out of years of experience, that you can't yet see.

Agreed.

> I realistically think this is a battle you might just as well not get
> yourself into.  There are lots of sharp point edges around, and as a
> relative novice, you're liable to get yourself cut up pretty badly.

I don't want to get into any battle. I just want to make some decent
statements that help me and other people to get into Lisp and especially
Common Lisp. I am not interested in politics.

> My sense is that you're too new to Lisp for these to _truly_ be
> important issues to you.

I don't have a pure programmer's point of view, but a main part of my
job is to do programming language research. So these things matter to
me, although admittedly mostly in a theoretical sense, as of yet.

> > Among the things I can consider for a later version are the following.
> > 1) I can draw a better line between what statements are relevant before
> > the reader has opted for Common Lisp or for Scheme and what are
> > essentially relevant for Common Lisp only. 2) A similar guide could be
> > added for people who choose Scheme.
> >
> > It's too early for me to do 1). It's very unlikey that I will do 2)
> > because I don't expect to gain sufficient hands-on knowledge about
> > Scheme. However, I am happy to include links to similar introductions to
> > the Scheme world.
> 
> But by putting yourself in this position, you are putting yourself in
> a spot in between two camps of fanatics that are armed with lots of
> pointy sticks.  You're likely to _by accident_ say something that
> offends one side or the other /or both/, and thereby get both sides
> attacking _you_.
> 
> The fact that you "mean well" doesn't matter to the fanatics.
> 
> The fact that Salmund Rushdie (sp?  It's a transliteration from
> something like Arabic anyways! :-)) felt he had a lot of respect for
> Islam did not prevent an assasination contract from going out on his
> head.
> 
> Nobody's going to do _that_ over you doing a comparative essay on
> Scheme versus Common Lisp, but you're still not going to make the
> fanatics into friends out of presenting your own _Satanic Verses_.

I don't care about fanatics and dogmatists. People who start such
religious wars should be aware of the fact that they frighten away other
people from both Scheme and Common Lisp. I don't expect to be able to
make fanatics into friends, I'd rather ignore them.

I don't think that my guide discourages people to opt for Scheme - I
don't have a tendency to overrate the impact I can have on other people.

I am willing to make changes to my text in order to eliminate potential
resources for misunderstandings. Therefore, I need some constructive
feedback. I am very happy that I have already got quite a lot useful
feedback!

All the best,
Pascal

--
Pascal Costanza               University of Bonn
···············@web.de        Institute of Computer Science III
http://www.pascalcostanza.de  R�merstr. 164, D-53117 Bonn (Germany)
From: Arthur Lemmens
Subject: Re: My guide to Lisp
Date: 
Message-ID: <3D6897C2.D546071B@xs4all.nl>
Pascal Costanza wrote:

> I have written a summary of what I have found out and made it available 
> recently at http://www.pascalcostanza.de/lisp/guide.html. Please let me 
> know what you think.

That's a nice article. Thanks.

Just one small comment that hasn't been mentioned yet.

You write: "Allegro Common Lisp and CLISP offer Unicode support, other
implementations don't." That's not correct. Lispworks offers Unicode support,
and I believe Brian Spilsbury is working on adding Unicode support to CMUCL.

Arthur Lemmens
From: Paolo Amoroso
Subject: Re: My guide to Lisp
Date: 
Message-ID: <ANtoPZWSxQ4psLKxqniL7N0pyWNZ@4ax.com>
On Thu, 22 Aug 2002 16:15:33 +0200, Pascal Costanza
<········@cs.uni-bonn.de> wrote:

> Lisp and digged deeply into it for the last few months. I have written a
> summary of what I have found out and made it available recently at
> http://www.pascalcostanza.de/lisp/guide.html. Please let me know what
> you think.

One more note on section "13. The LOOP Facility". Here is an insightful
comp.lang.lisp article by Kent Pitman on the "LOOP paradox":


http://groups.google.com/groups?selm=sfw4reosf6l.fsf%40shell01.TheWorld.com


Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README