This is still a work in progress: currently
52 pages in length, with a target length of 150 pages.
The working title is: "Loving Lisp, or the
Savy Programmer's Secret Weapon".
My goal is to write something that an experienced
programmer can work through in a couple of
evenings to see if she likes Common Lisp. I am
purposely leaving out some material (not covering
property lists, instead providing material on
hash tables, etc., etc.). I provide a web link
to Steele's CLTL for readers who decide that Lisp
suites them, so they can read a complete spec on the
language.
If you are kind enough to take the time to review this
early edition, please email me directly with reports
on errors and suggestions for changes to the structure
of the book.
The ZIP file containing the book in its present
form is available at www.markwatson.com in the
Open Content page.
Thanks,
Mark
Mark Watson <·····@markwatson.com> writes:
> My goal is to write something that an experienced
> programmer can work through in a couple of
> evenings to see if she likes Common Lisp. I am
> purposely leaving out some material (not covering
> property lists, instead providing material on
> hash tables, etc., etc.). I provide a web link
> to Steele's CLTL for readers who decide that Lisp
> suites them, so they can read a complete spec on the
> language.
Probably better to include a link to the Hyperspec, as CLTL doesn't
actually describe the standard (nothing wrong with linking to it, but
the Hyperspec is definitive).
-Doug
From: Kenny Tilton
Subject: The Parentheses Myth (was Re: new free web book on Common Lisp)
Date:
Message-ID: <3CF6B7FC.8659346B@nyc.rr.com>
I want to respond here on one point because I have been looking for a
chance to rant on this for a while.
"I learned to program Lisp in 1974 and my professor half-jokingly told
us that Lisp was an
acronym for Lots-of Irritating Superficilous Parenthesis. There is some
truth in this, but
you will quickly get used to the parenthesis, especially if you use an
editor like Emacs that
automatically indents Lisp code for you and hilights the opening
parenthesis for every closing
parenthesis that you type."
I would replace "There is some truth in this..." with "Nonsense.",
pretty much for the reasons you gave, except that I would strengthen the
last bit by pointing out editing is easier thanks to the parens.
I say "Parentheses Myth" because no one ever spent a week on Lisp and
did not get used to parentheses or a month and not come to appreciate
the auto-indenting and ability to edit in sexpr chunks.
Yet the Dylan crowd dumped prefix as a marketing ploy. Sure, lotsa folks
talk about prefix vs infix, but the Dylan crowd proved prefix is not a
Lisp-adoption issue with a very costly experiment. If they had thought
about it for a minute they might have realized, again:
No one ever spent a week on Lisp and did not get used to
prefix/parentheses. Get over it.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"Harvey has overcome not only time and space but any objections."
Elwood P. Dowd
From: Mark Watson
Subject: Re: The Parentheses Myth (was Re: new free web book on Common Lisp)
Date:
Message-ID: <3CF6C7B6.7040308@markwatson.com>
Hello Kenny,
re: parens, Dylan:
I stopped experimenting with Dylan when it was announced that
the Lisp mode would go away.... :-)
re: parens:
Sorry, that comment stays in - it is such a fond memory, that
lecture that was my first taste of Lisp :-)
BTW, Thanks for your suggestions (send in a private email)!
-Mark
From: David Golden
Subject: Re: The Parentheses Myth (was Re: new free web book on Common Lisp)
Date:
Message-ID: <tL2K8.8350$04.24116@news.iol.ie>
Kenny Tilton wrote:
> No one ever spent a week on Lisp and did not get used to
> prefix/parentheses. Get over it.
>
Well, most of the stuff you do in C-like languages is, in fact,
prefix, since most of the stuff you do tends to be function calls.
The difference is that c uses foo(bar, baz); and lisp uses (foo bar baz)
- both prefix. It's mainly the few infix arithmetic and dereference
expressions in C that vary from c's prefix system.
People often focus on the classical (+ 1 2) examples (since lisp is
all prefix expressions rather than a mixture of infix and prefix
expressions and statements), and neglect to mention that the vast bulk of C
stuff is in fact prefix too, just with the opening parenthesis after the
head rather than before.
I sometimes wonder if one merely changed that opening-paren-position bit of
lisp syntax, without worrying about infix v.s. prefix, would thousands of c
programmers suddenly "get" lisp... (It seems to work quite well for what a
c programmer would think of as programs, but what a c programmer would
think of as data structures look a bit funny...)
(amli bert (crog dimp) elpo fnord)
to
amli(bert crog(dimp) elpo fnord)
It's a bit "wrong" looking if one considers
it a print of a data structure, but if amli and crog are
functions, then it looks almost "right" to a c programmer - stick commas in
too and a c programmer will probably read it no bother.
amli(bert, crog(dimp), elpo, fnord)
--
Don't eat yellow snow.
From: Erik Naggum
Subject: Re: The Parentheses Myth (was Re: new free web book on Common Lisp)
Date:
Message-ID: <3231925655526163@naggum.net>
* David Golden
| I sometimes wonder if one merely changed that opening-paren-position bit
| of lisp syntax, without worrying about infix v.s. prefix, would thousands
| of c programmers suddenly "get" lisp... (It seems to work quite well for
| what a c programmer would think of as programs, but what a c programmer
| would think of as data structures look a bit funny...)
This is in fact quite easy to automate. To give the feel for this way of
writing the code, I have taken the liberty to convert a roman-numeral
parser to the new style. Please note that this was made a lot easier
because I now write my code in Common Salt syntax instead of just Common
Lisp. In Common Salt, <> and () are both list operators, but <> hold an
evaluatable form (or an XML-style "element"), whereas () simply hold a
list as data. (This is at one level mere syntax -- the point is to
support different "readers" in each element; the "readers" of macros and
special operators know how to parse the rest of their input, but if you
ask for it, you get more information.) E.g.,
<defun parse-roman-digit-sequence (count roman start end digit unit half cont fail)
<cond (<^< count 0> <funcall fail nil>)
(<= start end> 0)
(<equalp <char roman start> <second unit>>
<+ <first digit>
<parse-roman-digit-sequence
<1- count> roman <1+ start> end digit unit half cont fail>>)
(t
<funcall cont
roman start end <cdr digit> <cdr unit> <cdr half> fail>)>>
Why Common Salt? Common Salt is NaCl, the Next Advancement in Common Lisp.
^ has the same function as \ in Common Lisp. \ got in the way too much.
Now, this can easily be turned into the not-quite-prefix syntax:
in-package (:cl-user)
defun (parse-roman-digit-sequence, (count, roman, start, end, digit, unit, half, cont, fail),
cond ((< (count, 0), funcall (fail, nil)),
(= (start, end), 0),
(equalp (char (roman, start), second (unit))
+ (first (digit),
parse-roman-digit-sequence
(1- (count), roman, 1+ (start), end, digit, unit, half, cont, fail))),
(t
funcall (cont,
roman, start, end, cdr (digit), cdr (unit), cdr (half), fail))))
defun (parse-old-roman-digit, (roman, start, end, digit, unit, half, fail),
cond ((= (start end) 0),
(null (digit), funcall (fail, nil)),
(equalp (char (roman, start), first (half))
+ (* (first (digit), 5),
parse-old-roman-digit
(roman, 1+ (start), end, digit, unit, cons (nil, cdr (half)), fail))),
(t
parse-roman-digit-sequence
(4, roman, start, end, digit, unit, half, #'parse-old-roman-digit, fail))))
defun (parse-new-roman-digit, (roman, start, end, digit, unit, half, fail),
cond ((= (start, end) 0),
(null (digit), funcall (fail, nil)),
(and (< (1+ (start), end),
equalp (char (roman, start), second (unit)),
equalp (char (roman, 1+ (start)), first (unit)))
+ (* (first (digit), 9),
parse-new-roman-digit
(roman, + (2, start), end, cdr (digit), cdr (unit), cdr (half), fail))),
(and (< (1+ (start), end),
equalp (char (roman, start), second (unit)),
equalp (char (roman, 1+ (start)), first (half)))
+ (* (first (digit), 4),
parse-new-roman-digit
(roman, + (2, start), end, cdr (digit), cdr (unit), cdr (half), fail))),
(equalp (char (roman, start), first (half)),
+ (* (first (digit), 5),
parse-new-roman-digit
(roman, 1+ (start), end, digit, cons (nil, cdr (unit)), cons (nil, cdr (half)), fail))),
(t
parse-roman-digit-sequence
(3, roman, start, end, digit, unit, half, #'parse-new-roman-digit, fail))))
defun (parse-roman-integer, (roman, &key, (start, 0), end, old-style),
"Return the integer represented by the valid roman numeral, or nil.
Old-style uses four consecutive digits of a unit, while new-style
uses the next smaller unit before the unit or half-unit.",
setq (end, or (end, length (roman))),
when (< (-1, start, end, 1+ (length (roman))),
flet (((parse-failure, (value),
return-from (parse-roman-integer, value))),
funcall (if (old-style, #'parse-old-roman-digit, #'parse-new-roman-digit),
roman, start, end, '(1000, 100, 10, 1), '(nil, #\M, #\C, #\X, #\I), '(nil, #\D, #\L, #\V),
#'parse-failure))))
I sort of feel like I have just re-invented Dylan, but I mostly hope
people are _really_ scared. (There are probably mistakes in the above.
If you go look for them, you prove several interesting things about your
psychology and realize that posting about it is yet another mistake.)
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
From: Paul F. Dietz
Subject: Re: The Parentheses Myth (was Re: new free web book on Common Lisp)
Date:
Message-ID: <3CF8C998.29535696@dls.net>
Erik Naggum wrote:
> I sort of feel like I have just re-invented Dylan, but I mostly hope
> people are _really_ scared.
More nauseated, actually. Yuck.
Paul
> Erik Naggum wrote:
>
> > I sort of feel like I have just re-invented Dylan, but I mostly hope
> > people are _really_ scared.
>"Paul F. Dietz" <·····@dls.net> wrote in message ······················@dls.net...
>
> More nauseated, actually. Yuck.
>
Erik should be more careful. Someone might actually try to implement this.
"Erik Naggum" <····@naggum.net> wrote in message ·····················@naggum.net...
>
> Why Common Salt? Common Salt is NaCl, the Next Advancement in Common Lisp.
> I mostly hope people are _really_ scared.
`Scared' isn't quite the word. `Nauseated' is closer.
In an attempt to throw the authorities off his trail, Erik Naggum <····@naggum.net> transmitted:
> defun (parse-roman-integer, (roman, &key, (start, 0), end, old-style),
> "Return the integer represented by the valid roman numeral, or nil.
> Old-style uses four consecutive digits of a unit, while new-style
> uses the next smaller unit before the unit or half-unit.",
> setq (end, or (end, length (roman))),
> when (< (-1, start, end, 1+ (length (roman))),
> flet (((parse-failure, (value),
> return-from (parse-roman-integer, value))),
> funcall (if (old-style, #'parse-old-roman-digit, #'parse-new-roman-digit),
> roman, start, end, '(1000, 100, 10, 1), '(nil, #\M, #\C, #\X, #\I), '(nil, #\D, #\L, #\V),
> #'parse-failure))))
Change the "," to ":" and you have _nearly_ reinvented Python. Nearly.
--
(reverse (concatenate 'string ········@" "enworbbc"))
http://www.cbbrowne.com/info/linuxxian.html
"A man without religion is like a fish without a bicycle."
-- Bertrand Russell
From: David Golden
Subject: Re: The Parentheses Myth (was Re: new free web book on Common Lisp)
Date:
Message-ID: <335K8.8359$04.24029@news.iol.ie>
Erik Naggum wrote:
> I sort of feel like I have just re-invented Dylan, but I mostly hope
> people are _really_ scared.
Yuck. Brain hurts.
Thanks for that graphic illustration of the ickiness...
It might be slightly less iffy (the C-like last bit, not the <> bit which
is alright I suppose, though not really my cup of tea) if there were no
space between the word and the opening paren, again a bit more like most
people's C i.e.
foo(blah, bloo, bling) or foo( blah, bloo, bling)
rather than
foo (blah, bloo, bling)
which seems to have foo "too separate" from the rest of the list.
But on the whole... yuck.
--
Don't eat yellow snow.
From: Kenny Tilton
Subject: Is foo(bar, baz) prefix? (was Re: The Parentheses Myth (was Re: new free web book on Common Lisp))
Date:
Message-ID: <3CF8FDC3.B961678C@nyc.rr.com>
David Golden wrote:
>
> Kenny Tilton wrote:
>
> > No one ever spent a week on Lisp and did not get used to
> > prefix/parentheses. Get over it.
> >
>
> Well, most of the stuff you do in C-like languages is, in fact,
> prefix,
Well, my point was about the Parentheses Myth, or "Lisp syntax is an
obstacle to adoption." Let's not quibble over how we detail the
difference between C and Lisp syntax (should I have said
"sexpr"?)....oh, ok, let's...
Graham agrees with you "sort of". But I parse foo(bar, bax) as:
<func><arg-list> where (lazily) <arg-list> => (<arg>, <arg>....)
Lisp I see as (sloppily): (func arg arg arg...)
textual before-ness is the only thing I see in common. Is textual
before-ness "prefix notation"?
In lisp the operator (in the most general sense) swims with the
arguments and is differentiated from them only its leading (prefix)
position. That is nothing like C, and why (I wager) Graham "sort of"ed
his description of C function calls as prefix.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"Harvey has overcome not only time and space but any objections."
Elwood P. Dowd
From: Paolo Amoroso
Subject: Re: The Parentheses Myth (was Re: new free web book on Common Lisp)
Date:
Message-ID: <p9f8PMTe9VNGpSO3bgJx50ErL5VW@4ax.com>
On Thu, 30 May 2002 23:30:52 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
> "I learned to program Lisp in 1974 and my professor half-jokingly told
> us that Lisp was an
> acronym for Lots-of Irritating Superficilous Parenthesis. There is some
> truth in this, but
[...]
> I would replace "There is some truth in this..." with "Nonsense.",
As I have said to Mark, it would be more appropriate to point out that
Lisp's parentheses are not just an idiosyncrasy, a mere syntactic accident
that can be tolerated with the help of a good editor such as Emacs, but the
key to one of Lisp's most powerful--and possibly unparalleled--features.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
From: Mark Watson
Subject: Re: new free web book on Common Lisp: enough comments for now
Date:
Message-ID: <3CF7B7A3.7000506@markwatson.com>
I would like to thank everyone who submitted suggestions for
improving the CL web book!
I have incorporated most suggestions and I updated the PDF file
for the book (and the readme.html file) on my web site.
I am going to take another 5 or 6 weeks (of free time) to finish
the rest of the material, then I will make another announcement
asking for more suggestions.
One of my motivations for writing free web books is that as a published
author I frequently get requests from teachers and students from
"third world" countries for free reprints of my books for use in school.
Unfortunately, most publishers do not allow this and I have had to say
"no" to such requests too often for it not to bother me. After
the Lisp web book is "done" so it is useful to home hobbiests
and professional programmers, I would appreciate further input from
teachers concerning any defects that would keep it from being useful
for introductory classes.
Thanks again,
Mark
-- Mark Watson, author and consultant
-- www.markwatson.com - Open Source and Open Content
-- www.knowledgebooks.com - Commercial artificial intelligence software
From: Bill Clementson
Subject: Re: new free web book on Common Lisp: enough comments for now
Date:
Message-ID: <wkvg94ynsn.fsf@attbi.com>
Mark,
Thank you for creating your free web book on Common Lisp. I look
forward to tracking its progress as you add material to the book.
One thing that you might want to consider adding to the book is
a link to the CL Cookbook page on "Setting up an IDE with Emacs on
Windows". I wrote the page as an attempt to give novice Lisp users
a step-by-step guide to setting up Emacs on MS Windows for use with
CL (this seems to be a FAQ that newbies always ask as they start
learning CL). The page includes instructions for the installation &
setup of CLISP, ACL, LW, & Corman - the most popular CL's available
under Windows. It also includes setup instructions for ILISP and a
default .emacs file that people can use to get started.
Thanks again for your contributions (this and previous ones) to the
CL community.
--
Bill Clementson