My guide to Lisp
Pascal Costanza
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
mailto:cost...@web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
Pascal Costanza
Duane Rettig
> 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 du...@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
thelifter
> 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.
Great article!
Could you also please summarize the Feyerabend project in a few lines?
Thank you,
TheLifter
Matthew Danish
> 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 <mda...@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."
Frode Vatvedt Fjeld
> 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
Pascal Costanza
>
> Pascal Costanza <cost...@cs.uni-bonn.de> wrote in message news:<3D64F2CE...@cs.uni-bonn.de>...
[...]
> > http://www.pascalcostanza.de/lisp/guide.html. Please let me know what
> > you think.
>
> Great article!
> Could you also please summarize the Feyerabend project in a few lines?
Noone can do it better like Richard Gabriel ;-) So here is a link
http://www.dreamsongs.com/Feyerabend/Feyerabend.html
Pascal Costanza
>
> 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!)
Raymond Toy
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
Thomas Stegen CES2000
> 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.
Barry Margolin
Pascal Costanza <cost...@web.de> wrote:
>thelifter wrote:
>>
>> Pascal Costanza <cost...@cs.uni-bonn.de> wrote in message
>news:<3D64F2CE...@cs.uni-bonn.de>...
>
>[...]
>
>> > http://www.pascalcostanza.de/lisp/guide.html. Please let me know what
>> > you think.
>>
>> Great article!
>> Could you also please summarize the Feyerabend project in a few lines?
>
>Noone can do it better like Richard Gabriel ;-) So here is a link
>http://www.dreamsongs.com/Feyerabend/Feyerabend.html
Well, if no one can do it better, I guess it's just impossible to do well.
I read that page when I first saw it in your guide, and I'm still just as
much in the dark about what they're doing. It just seems to be a vague,
idealistic "let's go back to square one and figure out how to program
computers the right way" thing. Unless I missed them, there were no links
to any specific techniques they've come up with. And given the momentum of
the current programming paradigms, I wish them good luck with a major
paradigm shift of this nature.
--
Barry Margolin, bar...@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.
Pascal Costanza
>
> Pascal Costanza <cost...@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 Costanza
>
> In article <3D663114...@cs.uni-bonn.de>,
> Pascal Costanza <cost...@web.de> wrote:
> >thelifter wrote:
[...]
> >> Could you also please summarize the Feyerabend project in a few lines?
> >
> >Noone can do it better like Richard Gabriel ;-) So here is a link
> >http://www.dreamsongs.com/Feyerabend/Feyerabend.html
>
> Well, if no one can do it better, I guess it's just impossible to do well.
> I read that page when I first saw it in your guide, and I'm still just as
> much in the dark about what they're doing. It just seems to be a vague,
> idealistic "let's go back to square one and figure out how to program
> computers the right way" thing. Unless I missed them, there were no links
> to any specific techniques they've come up with. And given the momentum of
> the current programming paradigms, I wish them good luck with a major
> paradigm shift of this nature.
OK, here is a little bit meta-information about the Feyerabend project:
as I understand it, it is mainly about having wild new ideas about what
could be done differently in computer science than it is done right now.
So it's more a brainstorm thing and there are no specific goals set (so,
of course, they cannot be reached ;).
There are projects that emerged from the Feyerabend project, like the
"Biological Framings of Problems in Computing"
(http://www.dreamsongs.com/Feyerabend/BiologicalFramings.html) or the
Extravegaria Workshop at this year's OOPSLA
(http://www.dreamsongs.com/Feyerabend/Extravagaria.html).
If you click around on rpg's website you will find many more intersting
topics.
Barry Margolin
Pascal Costanza <cost...@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.
Aleksandr Skobelev
> 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.
Pascal Costanza
>
> 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?
Duane Rettig
> Duane Rettig wrote:
> >
> > Pascal Costanza <cost...@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!" :-)
Jock Cooper
> 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'.
Christopher Browne
> OK, here is a little bit meta-information about the Feyerabend
> project: as I understand it, it is mainly about having wild new
> ideas about what could be done differently in computer science than
> it is done right now. So it's more a brainstorm thing and there are
> no specific goals set (so, of course, they cannot be reached ;).
It seems to amount to "we think there are some problems in computer
science, and we'd like to solve them."
That doesn't forcibly imply terribly much of anything about the
answers.
It's sort of like the (out of print) "Unix Hater's Guide;" that was a
book written about the evils of Unix by some people that hated Unix.
There were some legitimate points, but unfortunately it doesn't lead
the reader towards any sort of _useful_ resolution.
A facile reading of the authors' bios indicates that a bunch of them
work for Microsoft: is that to imply that Microsoft's products are the
answer? I hardly think so, as their products have flaws even more
gaping than the ones that Unix gets flogged for. A more careful look
at the bios shows that a number of the authors were ex-"Lisp Machine"
guys, and that _that_ may be more like their "Holy Grail." But the
book never suggests _any_ form of answer.
I think that until the "Feyerabend project" actually has some
_concrete_ techniques/theories/answers/solutions, it's just going to
amount to vague wishful thinking. If they are merely at the "asking
questions" or "criticizing the mainstream" point, there's not much
meaningful about it.
--
(concatenate 'string "cbbrowne" "@ntlug.org")
http://www3.sympatico.ca/cbbrowne/unixhaters.html
Why does the word "lisp" have an "s" in it?
Erann Gat
> > * 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.
Biep @ http://www.biep.org/
> If they are merely at the "asking questions"
> or "criticizing the mainstream" point,
> there's not much meaningful about it.
Hmm. Isn't that the step most people forget before coming up with an (in
hindsight) evil solution?
I wish people spent more time coming up with the right questions before
getting involved in finding answers..
--
Biep
Reply via any name whatsoever at the main domain corresponding to
http://www.biep.org
Christopher Browne
> 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 "gro.mca@" "enworbbc"))
http://cbbrowne.com/info/
Microsoft spel chekar vor sail, worgs grate !!
-- <lei...@inf.fu-berlin.de>, Felix von Leitner
Greg Menke
Perhaps there should be something like an "Adams 42nd Principle" which
states "The usefulness of an answer is proportional to the
meaningfulness of the problem statement."
Gregm
Dorai Sitaram
Pascal Costanza <cost...@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.
Thomas F. Burdick
> 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! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick
> 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.
Erik Naggum
| 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.
Christopher Browne
> * 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.
Ray Blaak
> 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,
bl...@telus.net The Rhythm has my soul.
Paolo Amoroso
<cost...@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.
I share the positive feedback expressed by others in this thread. I include
below some specific comments. They refer to version 1.01, 21/8/2002 of the
document.
> This document is in the public domain. You can freely copy and redistribute
> it and even reuse parts of it in your own work as long as you acknowledge
> my authorship.
If the document is in the public domain, I think you can't require that
users acknowledge your authorship. You can only ask this and hope users
comply.
> 7. Available implementations
[...]
> Allegro Common Lisp
There is a version of ACL free for personal use.
> CormanLisp
Ditto.
> PowerLisp
The PowerLisp code was released as open source. A new project has been set
up to maintain and further develop the system:
http://sourceforge.net/projects/powerlisp
Another good Lisp system for the Mac is OpenMCL, which is based on MCL:
> 10. More advanced basics
[...]
> Strings are a little bit complicated in Common Lisp for the following
> reasons.
The sequence forms also apply to strings.
> 12. Object-oriented features (CLOS)
[...]
> CLOS offers full object-orientation with classes, subclassing, multiple
> inheritance, multi-methods and before-, after- and around advices.
Your intended audience may not be familiar with method combination issues,
so it may be worth briefly introducing such concepts.
> 17. What is missing?
[...]
> Many things are not included in ANSI Common Lisp that are by now taken
> for granted in other, more fashionable programming languages. Among
> these features are: a proper module ("system construction") facility,
> Unicode support, a platform-independent GUI library, sockets and TCP/IP,
> XML, WebServices, and so on (add your favorite feature here).
For some thoughts about Lisp libraries you may read the comp.lang.lisp
article by Erik Naggum with Message-ID: <32373367...@naggum.no>.
I almost forgot: welcome to Lisp!
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
Fred Gilham
> It seems to amount to "we think there are some problems in computer
> science, and we'd like to solve them."
Actually it seems they are on to something more radical than that.
Here's a quote from the workshop announcement for 2003:
http://www.dreamsongs.com/Feyerabend/ETAPS03/index.html
Fifty years into the First Computing Era some of us in the
computing arena have come to realize we have made a false start
that cannnot be fixed, and for us to finally be able to produce
lasting, correct, beautiful, usable, scalable, enjoyable software
that stands the tests of time and moral human endeaveor, we need
to start over. Perhaps we will be able to salvage some of what we
have learned from the First Era, but we expect almost everything
except the most mathematical and philosophical fundamentals to be
brushed aside.
So they want to start over.
--
Fred Gilham gil...@csl.sri.com
I think it's pretty obvious that the worship of that false idol known
as the State has, in the 20th Century, had some very bad effects. The
historians I'm familiar with have settled on the number of dead as 177
million, although I?ve seen estimates of up to 200 million.
-Bob Wallace
Christopher Browne
>> PowerLisp
>
> The PowerLisp code was released as open source. A new project has been set
> up to maintain and further develop the system:
>
> http://sourceforge.net/projects/powerlisp
This URL reports that it is an "Invalid Project."
Are you thinking of:
http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/impl/powerlsp/0.html
http://www.cormanlisp.com/PowerLisp.html
http://ww.telent.net/cliki/PowerLisp
--
(concatenate 'string "chris" "@cbbrowne.com")
http://cbbrowne.com/info/oses.html
What would the world be like with no hypothetical situations?
Christopher Browne
> Christopher Browne <cbbr...@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
Ray Blaak
> 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
Arthur Lemmens
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
Petter Gustad
Ray Blaak <bl...@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
Paul F. Dietz
> 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
thelifter
> Noone can do it better like Richard Gabriel ;-) So here is a link
> http://www.dreamsongs.com/Feyerabend/Feyerabend.html
>
Ok,
one thing I was always thinking about since I'm very interested in AI
is the following:
1. Are there "processes" done by natural neural networks(Brains) that
CANNOT be simulated by conventional computers?
I think the answer to this question is terribly important. Because if
the answer is YES, possibly there will be no way to achieve human like
intelligence with computers. And then we must start thinking about how
to build a machine that can simulate a Brain?
OTOH if the answer is NO, it means that we can simulate a brain trough
software and we can focus more on software and forget the underlying
hardware.
Has this question already been answered by someone?
Thx...
PS: Just some additional food for thought: Are there electric circuits
that can not be simulated by software?
I know at least one answer: You can build a random number generating
circuit(measuring radioactive decay). But you cannot make the same
with software. If you do it by software it will generate a total
predictable sequence of numbers.
Ray Blaak
> Ray Blaak <bl...@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.
Erann Gat
thel...@gmx.net (thelifter) wrote:
> PS: Just some additional food for thought: Are there electric circuits
> that can not be simulated by software?
>
> I know at least one answer: You can build a random number generating
> circuit(measuring radioactive decay). But you cannot make the same
> with software. If you do it by software it will generate a total
> predictable sequence of numbers.
This is commonly believed, but it turns out not to be true. See
http://mathpages.com/rr/s9-08/9-08.htm
E.
Paolo Amoroso
<cost...@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 Amoroso
> In the last exciting episode, Paolo Amoroso <amo...@mclink.it> wrote::
> >> PowerLisp
> >
> > The PowerLisp code was released as open source. A new project has been set
> > up to maintain and further develop the system:
> >
> > http://sourceforge.net/projects/powerlisp
>
> This URL reports that it is an "Invalid Project."
I last checked this URL in September 2001, and assumed it still worked.
Apologies.
> Are you thinking of:
> http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/impl/powerlsp/0.html
> http://www.cormanlisp.com/PowerLisp.html
> http://ww.telent.net/cliki/PowerLisp
Yes.
Nicolas Neuss
> > * ``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.
Pascal Costanza
>
> On Thu, 22 Aug 2002 16:18:54 +0200, Pascal Costanza
> <cost...@cs.uni-bonn.de> wrote:
> > http://www.pascalcostanza.de/lisp/guide.html. Please let me know what
> > you think.
>
> I share the positive feedback expressed by others in this thread. I include
> below some specific comments. They refer to version 1.01, 21/8/2002 of the
> document.
> > PowerLisp
>
> The PowerLisp code was released as open source. A new project has been set
> up to maintain and further develop the system:
>
> http://sourceforge.net/projects/powerlisp
Except for announcements, I haven't seen any real sign of life for this
project. Where (in the net) is this happening?
> For some thoughts about Lisp libraries you may read the comp.lang.lisp
> article by Erik Naggum with Message-ID: <32373367...@naggum.no>.
I don't find this message - could you perhaps forward this to me?
> I almost forgot: welcome to Lisp!
Thanks a lot! ;-)
Pascal
--
Pascal Costanza University of Bonn
mailto:cost...@web.de Institute of Computer Science III
http://www.pascalcostanza.de Römerstr. 164, D-53117 Bonn (Germany)
Edi Weitz
> Paolo Amoroso wrote:
>
> > For some thoughts about Lisp libraries you may read the
> > comp.lang.lisp article by Erik Naggum with Message-ID:
> > <32373367...@naggum.no>.
>
> I don't find this message - could you perhaps forward this to me?
'groups.google.com/groups?selm=' and then add the Message ID, i.e
<http://groups.google.com/groups?selm=32373367...@naggum.no>
Edi.
Pascal Costanza
>
> In article <3D665F67...@cs.uni-bonn.de>, cost...@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 Costanza
Nicolas Neuss
> Nicolas Neuss wrote:
> >
> > Pascal Costanza <cost...@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.
Tim Bradshaw
> 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
Pascal Costanza
>
> In article <3D64F205...@cs.uni-bonn.de>,
> Pascal Costanza <cost...@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.
Nils Goesche
Maybe he wanted to say `offenbar'.
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x0655CFA0
Christopher Browne
> 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.
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 "gro.mca@" "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 <d...@motifzone.com>
Pascal Costanza
>
> Quoth Pascal Costanza <cost...@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,
Erann Gat
> Erann Gat wrote:
> >
> > In article <3D665F67...@cs.uni-bonn.de>, cost...@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.
Petter Gustad
> Petter Gustad <newsma...@gustad.com> writes:
> > Ray Blaak <bl...@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.
Christopher Browne
.. 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
Paolo Amoroso
<cost...@cs.uni-bonn.de> wrote:
> Paolo Amoroso wrote:
[...]
> > http://sourceforge.net/projects/powerlisp
>
> Except for announcements, I haven't seen any real sign of life for this
> project. Where (in the net) is this happening?
I suggest that you ask Roger Corman.
> > For some thoughts about Lisp libraries you may read the comp.lang.lisp
> > article by Erik Naggum with Message-ID: <32373367...@naggum.no>.
>
> I don't find this message - could you perhaps forward this to me?
I forward it separately.
Robert Braddock
> 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