Hi fellow LISPers, I have just slaved away at a new online tutorial for
newbies or those with no previous LISP experience. (NObies? :-)
http://www.lisperati.com
(be sure to read the addendum at
http://www.lisperati.com/addendum.html
before suggesting any corrections...)
The goal of this tutorial is twofold:
1. To take a non-LISP programmer along the straightest possible line so
that he/she can appreciate some of the coolest, tastiest nuggets of
programming power that LISP has to offer.
2. To explore the idea that Macros can be taught far more easily if
they are given a different name, due to the semantic load present in
this overused term. In my tutorial, I suggest the term SPEL as a simple
synonym (replacement?) of "Macro" that offers many advantages for
reasons outlined in the following essay:
http://www.lisperati.com/no_macros.html
Any feedback is greatly appreciated!
--
Conrad Barski, M.D. (concatenate 'string ·······@gm" "ail.com")
······@gmail.com wrote:
> 1. To take a non-LISP programmer along the straightest possible line so
> that he/she can appreciate some of the coolest, tastiest nuggets of
> programming power that LISP has to offer.
This is really good! I did some LISP, but never got around to macros (course
too short). I see what PG means by 'build the language up to the app'.. the
game-action macro was an inspired choice (so was the choice of game
programming). Glad you tackled the meaty problems, I think newbies spend
too much time mucking about with basic stuff & end up trying to do things
the non-lispy way.
cheers,
N
PS what I take away from this is that to write spels you need a basic
similarity of textual structure in the source code.. is that correct? that
ultimately it's just a source level transformation? Or is this my C macro
bias at work?
---
Nandan Bagchee
CIS / Ohio State
········@cse.ohiodashstate.edu
Eventually the pimps and drug dealers notice that the doctors and lawyers
have switched from Cadillac to Lexus, and do the same.
-- Paul Graham
OSU wrote:
>
> PS what I take away from this is that to write spels you need a basic
> similarity of textual structure in the source code.. is that correct? that
> ultimately it's just a source level transformation? Or is this my C macro
> bias at work?
>
It helps to keep the basic list structure when writing macros (spels).
However it is not mandatory. There are macros which can transform
things like infix math into Lisp sexpr math. Also the phrase "just
a source level transformation" is misleading. The tranformation of
a macro form to another can be done using the whole functionality of the
Lisp image. Variables can be created, context can be taken into
consideration, connections to web servers made, helper functions
can be created and compiled. Even foreign C code could be written,
compiled and dynamically linked with a Lisp's FFI. In C it is just
simple-minded substitution.
Potential Non Lispy Macro Examples:
(setf *calgary-merchants*
#!sql: select merchant.id from merchants where (merchant.city = 'Calgary');)
(publish "/echopage.html"
:virtual-host "home.com"
:mime-type "text/html"
:content
#!html: <html>
<head><title>Embedded Lisp Web Page</title></head>
<body>
You are accessing this page from !*source-ip-address*
</body>
</html>)
Wade
OSU <·········@mailite.com> writes:
> PS what I take away from this is that to write spels you need a basic
> similarity of textual structure in the source code.. is that correct? that
> ultimately it's just a source level transformation? Or is this my C macro
> bias at work?
Not exactly. That's the easiest, but you can have some other occurences.
(defmacro mul (x y)
(cond
((integerp x) ; a literal constant
(cond
((= 0 x)
0)
((= x (expt 2 (truncate (log x 2))))
`(ash y , (truncate (log x 2))))
((< x 10)
(let ((vs (gensym))(vy (gensym)))
`(let ((,vs 0)(,vy ,y)) (dotimes (i ,x) (incf s ,vy)))))
(t
`(* ,x ,y))))
(t ; a variable
`(* ,x ,y))))
(macroexpand-1 '(MUL 0 y))
==> 0, T
(macroexpand-1 '(MUL 4 y))
==> (ASH Y 2), T
(macroexpand-1 '(MUL 5 y))
==> (LET ((#:G1293623 0) (#:G1293624 Y))
(DOTIMES (I 5) (INCF S #:G1293624))), T
(macroexpand-1 '(MUL x y))
==> (* X Y), T
The textual structure of the generate source can vary quite a lot, and
still implement the same _abstraction_.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The world will now reboot; don't bother saving your artefacts.
In article <························@z14g2000cwz.googlegroups.com>,
······@gmail.com wrote:
> Hi fellow LISPers, I have just slaved away at a new online tutorial for
> newbies or those with no previous LISP experience. (NObies? :-)
>
> http://www.lisperati.com
>
> (be sure to read the addendum at
> http://www.lisperati.com/addendum.html
> before suggesting any corrections...)
>
> The goal of this tutorial is twofold:
>
> 1. To take a non-LISP programmer along the straightest possible line so
> that he/she can appreciate some of the coolest, tastiest nuggets of
> programming power that LISP has to offer.
>
> 2. To explore the idea that Macros can be taught far more easily if
> they are given a different name, due to the semantic load present in
> this overused term. In my tutorial, I suggest the term SPEL as a simple
> synonym (replacement?) of "Macro" that offers many advantages for
> reasons outlined in the following essay:
>
> http://www.lisperati.com/no_macros.html
>
> Any feedback is greatly appreciated!
That is <expletive deleted> awesome. Mind you, I am not good at reading,
so I just looked at the pictures. Brilliant. And I am glad to see QUOTE
dealt with up front, given the newbie fatality rate on that issue lately.
:)
kenny
Conrad Barski wrote:
> Hi fellow LISPers, I have just slaved away at a new online tutorial for
> newbies or those with no previous LISP experience. (NObies? :-)
>
> http://www.lisperati.com
Very impressive!! Great drawings, clear explanation, nice example code.
It's fantastic to see something so totally different from the usual boring
explanations of quote and macros.
The only thing I missed was a "To Be Continued" line at the end. (Oh, and
there's is a misplaced "for" and a missing "-ing" in the sentence "Even for
experienced LISP programmers would have to put some thought into create a
monstrosity like this".)
It would be great if you could find a publisher for this. Maybe Markus Fix
would be interested?
--
Arthur
······@gmail.com wrote:
> Hi fellow LISPers, I have just slaved away at a new online tutorial for
> newbies or those with no previous LISP experience. (NObies? :-)
>
> http://www.lisperati.com
Beautiful! Simply amazing!
> 2. To explore the idea that Macros can be taught far more easily if
> they are given a different name, due to the semantic load present in
> this overused term. In my tutorial, I suggest the term SPEL as a simple
> synonym (replacement?) of "Macro" that offers many advantages for
> reasons outlined in the following essay:
SPEL is certainly closer to the truth about Lisp macros. A SPEL enlarges
your active vocabulary, but it drains your Mana during debugging. Very appropriate.
-fix
--
------- Markus Fix http://www.bookfix.com/ --------
--------Creating the Programmer's Library----------
Markus Fix wrote:
> ······@gmail.com wrote:
>
>> Hi fellow LISPers, I have just slaved away at a new online tutorial for
>> newbies or those with no previous LISP experience. (NObies? :-)
>>
>> http://www.lisperati.com
>
> Beautiful! Simply amazing!
I'd like http://www.lisperati.com/different.jpg as a T-shirt. ;)
Pascal
--
The big bang way only works for god, everybody else has to use
evolution. - David Moon
Pascal Costanza wrote:
> I'd like http://www.lisperati.com/different.jpg as a T-shirt. ;)
I seriously thought about making that the picture, when I posted it on
the c2 wiki. It really doesn't seem like there are enough crazy Lisp
flamewars there right now.
There's something about that picture.
> The big bang way only works for god, everybody else has to use
> evolution. - David Moon
A quick Google didn't pick that quote up. Was that from some talk?
MfG,
#\Tayssir
Tayssir John Gabbour wrote:
>>The big bang way only works for god, everybody else has to use
>>evolution. - David Moon
>
> A quick Google didn't pick that quote up. Was that from some talk?
It's from one of the "dynamic languages wizards" panels - see
http://www.ai.mit.edu/projects/dynlangs/wizards-panels.html
Pascal
--
The big bang way only works for god, everybody else has to use
evolution. - David Moon
If somebody else wants to take the initiative of doing some marketing
and creating a nice website for it (i.e. more than just the generic
cafepress page), I'd be glad to take the Lisp vs. other languages motif
from the blackboard of the cartoon and make it into a more polished
design for a tshirt.
--Conrad (concatenate 'string ·······@gm" "ail.com")
On 2004-12-06 15:25:25 -0500, ······@gmail.com said:
> I'd be glad to take the Lisp vs. other languages motif
> from the blackboard of the cartoon and make it into a more polished
> design for a tshirt.
I think you might want to include the Lisp Wizard as well - he adds
quite a bit to that particular cartoon (IMHO, of course).
Well done all around - I thoroughly enjoyed it.
regards,
Ralph
From: Svein Ove Aas
Subject: Re: Casting SPELs in Lisp - The Comic Book!
Date:
Message-ID: <cp281r$s1h$1@services.kq.no>
Pascal Costanza wrote:
>
> Markus Fix wrote:
>> ······@gmail.com wrote:
>>
>>> Hi fellow LISPers, I have just slaved away at a new online tutorial for
>>> newbies or those with no previous LISP experience. (NObies? :-)
>>>
>>> http://www.lisperati.com
>>
>> Beautiful! Simply amazing!
>
> I'd like http://www.lisperati.com/different.jpg as a T-shirt. ;)
>
Ooh... t-shirty goodness...
We could probably get cafepress to do that.
······@gmail.com writes:
> Hi fellow LISPers, I have just slaved away at a new online tutorial for
> newbies or those with no previous LISP experience. (NObies? :-)
>
> http://www.lisperati.com
Holy bit! :) By the way, "lisperati" sounds similar to "disperati",
which is the Italian for "desperate".
Thanks for the great resource,
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (see also http://clrfi.alu.org):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Paolo Amoroso <·······@mclink.it> writes:
> ······@gmail.com writes:
>
>> Hi fellow LISPers, I have just slaved away at a new online tutorial for
>> newbies or those with no previous LISP experience. (NObies? :-)
>>
>> http://www.lisperati.com
>
> Holy bit! :)
Yes, _very_ nice stuff.
> By the way, "lisperati" sounds similar to "disperati", which is the
> Italian for "desperate".
My association was with 'iluminati' or 'illuminati' :P
Regards, Szymon.
The intention was to reference "literati" and "digerati".
Given the cult-like nature of the lisp community, I suppose
"illuminati" works as well :)
"Desperate" i suppose isn't totally unreasonable either ;)
-Conrad
Ingvar wrote:
> Szymon <············@o2.pl> writes:
>
> > Paolo Amoroso <·······@mclink.it> writes:
> >
> > > ······@gmail.com writes:
> > >
> > >> Hi fellow LISPers, I have just slaved away at a new online
tutorial for
> > >> newbies or those with no previous LISP experience. (NObies? :-)
> > >>
> > >> http://www.lisperati.com
> > >
> > > Holy bit! :)
> >
> > Yes, _very_ nice stuff.
>
> It was certainly interesting.
>
> > > By the way, "lisperati" sounds similar to "disperati", which is
the
> > > Italian for "desperate".
> >
> > My association was with 'iluminati' or 'illuminati' :P
>
> Oh? I was thinking "literati".
>
> //Ingvar
> --
> "No. Most Scandiwegians use the same algorithm as you Brits.
> "Ingvar is just a freak."
> Stig Morten Valstad, in the Monastery
That's awesome!
Very creative to make the code a text adventure game. As well as
explaining the basic clearly and non-guruish-ly :)
I've already refered a freiend to it.
BTW, google groups 2 kicks butt!!!
--
Certum quod factum.
Philip Haddad
That's awesome!
Very creative to make the code a text adventure game. As well as
explaining the basic clearly and non-guruish-ly :)
I've already refered a freiend to it.
BTW, google groups 2 kicks butt!!!
--
Certum quod factum.
Philip Haddad
On Mon, 06 Dec 2004 16:52:29 -0800, philip.haddad wrote:
> That's awesome!
> Very creative to make the code a text adventure game. As well as
> explaining the basic clearly and non-guruish-ly :)
> I've already refered a freiend to it.
Agreed, bloody fantastic! A nice gentle, humorous introduction, but with
plenty of "meat" to it. I've referred two friends to it already.
Thanks,
Bill.
······@gmail.com writes:
> Hi fellow LISPers, I have just slaved away at a new online tutorial for
> newbies or those with no previous LISP experience. (NObies? :-)
>
> http://www.lisperati.com
This is just great stuff! I don't know what more to say. :)
Just a couple of small nits:
1. The "old", pre-GAME-ACTION version of WELD does not SETF
*CHAIN-WELDED*.
2. The first line of the body of the GAME-ACTION SPEL is indented too
much.
3. Indentation is accomplished with a mixture of tabs and spaces.
People who copy & paste the code and use a tab-width different from
yours might find the indentation of the code a bit odd. I greatly
prefer the use of spaces only.
Kind regards,
Dirk Gerrits
······@gmail.com writes:
> Hi fellow LISPers, I have just slaved away at a new online tutorial for
> newbies or those with no previous LISP experience. (NObies? :-)
>
> http://www.lisperati.com
>
> (be sure to read the addendum at
> http://www.lisperati.com/addendum.html
> before suggesting any corrections...)
>
My first impression: Lovely!
My demand: I want to translate it into Turkish,
including the baloons. If you can bother yourself
to put my translations in the baloons, I can handle
the remaining work by myself. I want to introduce
Common Lisp to Turkish speaking computer community
however there are many programmers who do not know
English very well so a fancy beginner tutorial like
that one, in their mother tongue would motivate them
to learn more Common Lisp (and English as well :)
--
Emre Sevinc
eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr
······@gmail.com writes:
> If you give me the translations, I'll be glad to change the captions.
> -Conrad (concatentate 'string ·······@gm" "ail.com")
>
Cool. BTW, what about the licence, copyright, etc. situation
of the text? Which one do you prefer? To publish the
Turkish translation (with Turkish baloon captions)
on your website or do you consider it be published on
some other mirror sites, too?
--
Emre Sevinc
eMBA Software Developer Actively engaged in:
http:www.bilgi.edu.tr http://ileriseviye.org
http://www.bilgi.edu.tr http://fazlamesai.net
Cognitive Science Student http://cazci.com
http://www.cogsci.boun.edu.tr
The text has a creative commons license (you can do whatever you want
with it, as long as you give me credit)
> To publish the
> Turkish translation (with Turkish baloon captions)
> on your website or do you consider it be published on
> some other mirror sites, too?
I'll put it on my webserver as a link on the main page- If you want to
put it on a separate site as well, mirrors are no problem.
-Conrad
(message (Hello ·······@gmail.com)
(you :wrote :on '(5 Dec 2004 17:58:46 -0800))
(
d> http://www.lisperati.com
looks like here's a bug:
(defun walk-direction (direction)
(let ((next (assoc direction (cdr (assoc *location* *map*)))))
(cond (next (setf *location* (third next)) (look))
(t '(you cant go that way.)))))
cdr in (cdr (assoc *location* *map*)) should be cddr, as it was in
#'describe-paths
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
(prin1 "Jane dates only Lisp programmers"))
(message (Hello ·······@gmail.com)
(you :wrote :on '(6 Dec 2004 14:13:16 -0800))
(
d> great catch! luckily, its not noticable- Still, a pretty bad
d> mistake...
i think plists can decrease confusion with all this cddr, second, third..
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
(prin1 "Jane dates only Lisp programmers"))
I'm afraid I have to admit that in one of the early chapters of PG's
ANSI Common Lisp (my introduction to lisp) it said that plists are a
_bad_ thing, so I never got around to learning them, even though that
was a long time ago- How pathetic is that? :)
-Conrad
······@gmail.com wrote:
> I'm afraid I have to admit that in one of the early chapters of PG's
> ANSI Common Lisp (my introduction to lisp) it said that plists are a
> _bad_ thing, so I never got around to learning them, even though that
> was a long time ago- How pathetic is that? :)
>
> -Conrad
>
It looks and reads great as is.
Why introduce a new data type when not needed ?
(Same reason why you did not use dotted notation).
May be you can just add a line at the end saying you have introduced
0.01% features/power of CL in this tutorial :)
My 2c
Thanks for the fun and education.
-Antony
······@gmail.com wrote:
> I'm afraid I have to admit that in one of the early chapters of PG's
> ANSI Common Lisp (my introduction to lisp) it said that plists are a
> _bad_ thing, so I never got around to learning them, even though that
> was a long time ago- How pathetic is that? :)
I don't know the exact context of this discussion, but in my experience
plists can be very handy in some cases. There are situations when they
are better than alists and vice versa, and both alists and plists can be
more efficient than hashtables when the number of associations is below
50 or 60 (on a few implementations that I have checked under Mac OS X).
However, the most straightforward data structure for newbies who know
about other languages is probably the hashtable. You don't loose much
time explaining what a hashtable is, while alists and plists require a
certain amount of handwaiving in the beginning.
I don't understand why Paul Graham and other (mostly "old") Lispers
don't like plists. (Would be interesting to know more about it.)
Pascal
--
The big bang way only works for god, everybody else has to use
evolution. - David Moon
From: Duane Rettig
Subject: Mapping styles (was Re: Casting SPELs in Lisp - The Comic Book!)
Date:
Message-ID: <4mzwqrsd4.fsf_-_@franz.com>
Pascal Costanza <········@web.de> writes:
> ······@gmail.com wrote:
> > I'm afraid I have to admit that in one of the early chapters of PG's
> > ANSI Common Lisp (my introduction to lisp) it said that plists are a
> > _bad_ thing, so I never got around to learning them, even though that
> > was a long time ago- How pathetic is that? :)
>
> I don't know the exact context of this discussion, but in my
> experience plists can be very handy in some cases. There are
> situations when they are better than alists and vice versa, and both
> alists and plists can be more efficient than hashtables when the
> number of associations is below 50 or 60 (on a few implementations
> that I have checked under Mac OS X).
>
>
> However, the most straightforward data structure for newbies who know
> about other languages is probably the hashtable. You don't loose much
> time explaining what a hashtable is, while alists and plists require a
> certain amount of handwaiving in the beginning.
Alists, plists, and hash-tables are best explained as mappings of
indicators onto values. They have different characteristics which
make them useful for various circumstances.
> I don't understand why Paul Graham and other (mostly "old") Lispers
> don't like plists. (Would be interesting to know more about it.)
I don't know how others view plists, but I certainly don't view
them as obsolete. One danger of using plists on symbols is that these
tend to be global in nature, since the symbols tend to be interned.
This can lead to conflicting usages unless the indicators are chosen
wisely to not clash with other potential indicator usages from
different modules. Other than that, plists are, like alists, very
simple to use and carry less space overhead than hash-tables when
the mapping set is small. The watchword here is to be careful. Use
the appropriate tool for the job at hand.
I use both hash-tables and plists for my environments access module.
The hash-tables are for the lexical mappings, and the plists are
for the global mappings. Note that neither mapping is attached directly
to a symbol, unless in the global (null lexical) environment, and even
then there might be a mapping of non-symbolic names to values (consider,
for example, function names such as (setf foo) or, in some lisps, extended
function names like (flet foo bar), which must have their own mappings
without hanging them on symbols).
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
From: xstream
Subject: Re: Mapping styles (was Re: Casting SPELs in Lisp - The Comic Book!)
Date:
Message-ID: <9qqtd.2747$ii5.584@fe06.lga>
"Duane Rettig" <·····@franz.com> wrote in message
·····················@franz.com...
>
> Alists, plists, and hash-tables are best explained as mappings of
> indicators onto values. They have different characteristics which
> make them useful for various circumstances.
>
For those of us (non SW engineers that is) who do however use Common Lisp
(heavily in my case) as a tool in other endeavors (e.g. simulation tool
development tool for VLSI chips specification, linear regression functional
and behavioral verification testing, Kalman filtering for RF signal tracking
purposes, etc.) Duane is indirectly touching the heart of a rather major and
related problem.
One learns Lisp (in my world at least) because one first hears that it is a
powerful language and decides to tackle it usually after an eye-opening demo
of a home-brewn solution. One practices and learns by doing until one day
one finds oneself (in this same world) in a position where choosing the
optimal "freaking data structure of choice" is the problem. As far as I know
there has been no comprehensive coverage of this field for non-SW engineers
who happen to be relatively strong users of Lisp. Take my own case for
example: over the years I have "eaten" everything from stone-age Allen's
Lisp internals, to Winston (all 3 editions), to Touretzky, to Tatar, to
Wozenscraft, to Abelson/Sussman I and II, to Norvig, to Nilsson, to Graham
I, II and largely unrelated III, to Keene, to Queinnec, to Kicsales, to
Tanimoto, and of course to the Language reference II by Steele and I have
never seen an attempt to show systematically how one picks the correct data
structure for what purpose. Of course one cannot span the application space,
but one can certainly try to give a list of typical examples from a wide
range of applications ultimately showing the ubiquitous capabilities of Lisp
in areas from financial derivatives to say regular expressions etc.
One major aspect of the transcendental beauty (I call it "metabeauty") of
Lisp is that there is an infinite way of mapping things to things (including
Duane's "indicators to values" as a .... subset). A tree can for instance be
encoded in a zillion different ways. Some are more intuitive and easier to
dream of than others. Which ones are better though? I realize of course that
"better" means different things at different points in time when
constraints/priorities/goals are different, but still I believe that there
is a gaping literature hole in this regard. Experienced Lispers do acquire
this wisdom by time and sheer exposure to challenges. Granted when one
experiments just for the fun of it who cares if the damn thing conses its
way to perdition? But what if someone (I repeat non-professional SW
engineer) could find somewhere some guidance as to what data structure and
why should be preferred if not outright chosen? One looks for example at
Kenny Tilton's Cells approach and one cannot help but admire both the
creator and his creation. My message here is simple: Don't underestimate the
problem newbies have in trying to harness the mega-power of infinite data
structure choices that are offered by Lisp. This is like a young driver
setting his right foot on the gas pedal of his father's hotrod for the first
time. Highly exciting but rather dangerous due to profoundly inadequate
experience! (I will grant you that my example may be slighly biased by a bad
icestorm we are currently experiencing in the northeastern US).
> I don't know how others view plists, but I certainly don't view
> them as obsolete. One danger of using plists on symbols is that these
> tend to be global in nature, since the symbols tend to be interned.
> This can lead to conflicting usages unless the indicators are chosen
> wisely to not clash with other potential indicator usages from
> different modules. Other than that, plists are, like alists, very
> simple to use and carry less space overhead than hash-tables when
> the mapping set is small. The watchword here is to be careful. Use
> the appropriate tool for the job at hand.
>
> I use both hash-tables and plists for my environments access module.
> The hash-tables are for the lexical mappings, and the plists are
> for the global mappings. Note that neither mapping is attached directly
> to a symbol, unless in the global (null lexical) environment, and even
> then there might be a mapping of non-symbolic names to values (consider,
> for example, function names such as (setf foo) or, in some lisps, extended
> function names like (flet foo bar), which must have their own mappings
> without hanging them on symbols).
>
Take Duane's choices for instance about hash tables and plists when it comes
down to his environment access module. There IS of course some serious logic
behind his choices as to what data structures fit lexical environments and
why and what is best suited to global environments instead. Even a few years
after I started using Lisp, I would not have been able to understand why he
says this versus that. Hash table of what? How about hierarchical data
meta-structures? Walking say a tree of hash tables (thinking aloud) or use
extensible vectors (popable and pushable) of various types? This really
opens up eyes for people who are attracted to the endless power of Lisp.
If we Lisp-believers want to attract more and more new users into the Lisp
world, then I believe that this is something we may have to consider
creating at some point. I guess I personally wish this type of information
were available, organized, and easily accessible in some easy to find source
(invited paper or a series of chapters in a book) as opposed to a half-baked
set of incomplete recipes for a few and limited cases here and there in some
of the currently available books. It would have saved people like me
"bignum"erous white nights and trial-an-error sessions, not to mention
sparing me some of my ....grey hair. Although I consider myself an rather
advanced Lisp user I cannot claim having anything close to the same depth
and expertise that say Duane or Pascal or Kenny and so many others in this
group do when it comes to juggling Lisp internals. The result is that I am
always in awe when I see with what ease they choose sophisticated (and
usually unpredictable) data structures for different purposes and make it
always sound like it is a no brainer.
Just thinking aloud...
Panos C. Lekkas
Duane Rettig wrote:
> Pascal Costanza <········@web.de> writes:
>
>>However, the most straightforward data structure for newbies who know
>>about other languages is probably the hashtable. You don't loose much
>>time explaining what a hashtable is, while alists and plists require a
>>certain amount of handwaiving in the beginning.
>
> Alists, plists, and hash-tables are best explained as mappings of
> indicators onto values. They have different characteristics which
> make them useful for various circumstances.
Of course, you're right. However, the advantage of hashtables (in my
limited experience) is, when presenting them to Lisp newbies, that they
have most probably heard of that data structure in other languages, so
you can quickly proceed with the stuff that you really want to present.
Furthermore as a side effect, this gives some people the clue that the
standard Common Lisp library is more complete than they would have thought.
>>I don't understand why Paul Graham and other (mostly "old") Lispers
>>don't like plists. (Would be interesting to know more about it.)
>
> I don't know how others view plists, but I certainly don't view
> them as obsolete.
Good. ;)
Pascal
--
Pascal Costanza University of Bonn
·········@p-cos.net Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> writes:
> I don't understand why Paul Graham and other (mostly "old") Lispers
> don't like plists. (Would be interesting to know more about it.)
I think there's plists and then there's plists. The kind of property
lists Graham talks about in "Ansi Common Lisp" (p. 134) is the plist
associated with a symbol, the second definition in the hyperspec
glossary, accessed by GET and SYMBOL-PLIST.
This kind of property list is not used much by me, at least, nor have
I seen it in use in other code I'm working with. From my experience,
I would not argue with Graham that it's more or less obsolete.
The other kind of plists - the first definition in the hyperspec,
accessed by GETF - I find rather useful. When using keywords as keys,
I can apply MAKE-INSTANCE to them, and they are easy to serialize for
communication over sockets. Turning them into hashes in PHP or
Perl is easy.
I would disagree with anyone trying to obsolete them. Fortunately,
that's not what Graham does. From a cursory glance at the index of
"Ansi Common Lisp", it doesn't seem like he mentions this kind of
plist at all.
...Peder...
--
I wish a new life awaited _me_ in some off-world colony.
From: Szymon
Subject: plists / plist-bugs in PAIP (was: Casting SPELs in Lisp - The Comic Book!)
Date:
Message-ID: <858y8ab6co.fsf_-_@eva.rplacd.net>
·····@news.klingenberg.no (Peder O. Klingenberg) writes:
> Pascal Costanza <········@web.de> writes:
>
>> I don't understand why Paul Graham and other (mostly "old") Lispers
>> don't like plists. (Would be interesting to know more about it.)
Because, 'they' (Peter Norvig (in PAIP)) do not know how to use
them. (This is _joke_ of course. See rest of this article.)
> I think there's plists and then there's plists. The kind of property
> lists Graham talks about in "Ansi Common Lisp" (p. 134) is the plist
> associated with a symbol, the second definition in the hyperspec
> glossary, accessed by GET and SYMBOL-PLIST.
Btw, I think that (very) short symbol-plists are convinient when one
need a symbol with "two values" (if second value is meant to be used
less frequently).
Instead of: (setq foo (cons 1 2))
(setq foo 1)
(setf (get 'foo :value-2) 2)
(get 'foo :value-2) ==> 2
* * *
Abtw, I found funny 'bugs' in PAIP (pages 75,76) (of course this is
greatest book ever written ;)
"Property lists have a long history in Lisp, but they are failing ouf of
favor as new alternatives such as hash tables are introduced. There are
two main reasons why property lists are avoided. First, because symbols
and their property lists are global,"
Half true (ok symbols are global, but can be interned in diffrent packages).
CL-USER> (defpackage "FOO" (:export "BAR"))
#<The FOO package, 0/8 internal, 1/2 external>
CL-USER> (defpackage "BAZ" (:export "BAR"))
#<The BAZ package, 0/8 internal, 1/2 external>
CL-USER> (setf (get 'foo:bar :value) 'foshmoo)
FOSHMOO
CL-USER> (setf (get 'baz:bar :value) 'blah)
BLAH
CL-USER> (symbol-plist 'foo:bar)
(:VALUE FOSHMOO)
CL-USER> (symbol-plist 'baz:bar)
(:VALUE BLAH)
CL-USER> (symbol-plist 'baz)
NIL
"its easy to get conflicts when trying to put together two programs that
use property lists. If two programs use the same property for diffrent
purposes, they cannot be used together."
Think about packages...
"Even if two programs use _different_ properties on the same symbols,
they will slow each other down."
Do more thinking about packages...
"Second, property lists are messy. There is no way to remove quickly
every element of a table implemented with property lists."
[ "There is no way to remove quickly every element of a table
implemented with property lists." ]
hmm...
!! CL-USER> (setf (symbol-plist 'foo:bar) nil) ; [ <---- ]
!! NIL
!!
!! CL-USER> (symbol-plist 'foo:bar)
!! NIL
If one do not want to waste conses:
(setf (symbol-plist 'symbol) (copy-list '(:a 1 :b 2 :c 3 :d 4)))
==> (:A 1 :B 2 :C 3 :D 4)
(symbol-plist 'symbol)
==> (:A 1 :B 2 :C 3 :D 4)
;; slow
(loop for i in (symbol-plist 'symbol) by #'cddr do (setf (get 'symbol i) nil))
(symbol-plist 'symbol)
==> (:A NIL :B NIL :C NIL :D NIL)
_More_ effective way:
!! (setf (symbol-plist 'symbol) (copy-list '(:a 1 :b 2 :c 3 :d 4)))
!! ==> (:A 1 :B 2 :C 3 :D 4)
!! ;; fast
!! (loop for i on (cdr (symbol-plist 'symbol)) by #'cddr do (rplaca i nil))
!! (symbol-plist 'symbol)
!! ==> (:A NIL :B NIL :C NIL :D NIL)
"In contrast, this can be done trivially with CLRHASH on hash tables,
or by setting an assotiation list to NIL." [ <---- ]
doh!
* * *
> This kind of property list is not used much by me, at least, nor have
> I seen it in use in other code I'm working with. From my experience,
> I would not argue with Graham that it's more or less obsolete.
> The other kind of plists - the first definition in the hyperspec,
> accessed by GETF - I find rather useful. When using keywords as keys,
> I can apply MAKE-INSTANCE to them,
Good idea.
My solution (overcomplicated, your is better):
(apply #'mapc (make-instance 'class-foo :init-arg-1 <> :init-arg-2 <>) foo-inits)
foo-inits: ((init-arg-1-1 init-arg-1-2 ...) (init-arg-2-1 init-arg-2-1 ...))
> and they are easy to serialize for communication over sockets.
> Turning them into hashes in PHP or Perl is easy.
>
> I would disagree with anyone trying to obsolete them. Fortunately,
> that's not what Graham does. From a cursory glance at the index of
> "Ansi Common Lisp", it doesn't seem like he mentions this kind of
> plist at all.
Regards, Szymon.
Szymon <············@o2.pl> writes:
> "Second, property lists are messy. There is no way to remove quickly
> every element of a table implemented with property lists."
>
> [ "There is no way to remove quickly every element of a table
> implemented with property lists." ]
>
> hmm...
>
> !! CL-USER> (setf (symbol-plist 'foo:bar) nil) ; [ <---- ]
> !! NIL
Of course this is, in general, a bad idea since the symbol's plist is
a shared resource of any code that has access to the symbol. So one
piece of code should only remove indicators from a plist that it put
there in the first place--clobbering the whole plist may clobber other
codes' indicators that were put there for other reasons.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
(message (Hello ·······@gmail.com)
(you :wrote :on '(6 Dec 2004 21:22:24 -0800))
(
here's one of possible usages of plists here:
(setf *map* '((living-room
:description (you are in the living-room of a wizards
house. there is a wizard snoring
loudly on the couch.)
:pathes ((west :how door :where garden)
(upstairs :how stairway :where attic)))))
(defun describe-location (location map)
(getf (cdr (assoc location map))
:description))
(defun describe-path (path)
`(there is a ,(getf (cdr path) :how)
going ,(getf (cdr path) :where) from here.))
(defun describe-paths (location map)
(apply #'append (mapcar #'describe-path
(getf (cdr (assoc location map))
:pathes))))
it's questionable if it's better - it's somewhat longer, but that who reads
it doesn't have to remember order of things in lists..
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
(prin1 "Jane dates only Lisp programmers"))
hmm... that does have an appeal to it, doesn't it? I'd probably want to
leave the tutorial as is due to the added complexity, but I could see
how that could be benificial in certain cases....
"Alex Mizrahi" <········@hotmail.com> writes:
Hi.
> (message (Hello ·······@gmail.com)
> (you :wrote :on '(6 Dec 2004 14:13:16 -0800))
> (
>
> d> great catch! luckily, its not noticable- Still, a pretty bad
> d> mistake...
>
> i think plists can decrease confusion with all this cddr, second, third..
or maybe symbol-macros to "rename" cddr, second, third...
Btw, I think that present state is OK. Do not overkill simple things...
Regards, Szymon.
ps. I just used plists in toy-blog-code-snippet --
I'm not very impressed...
url: [ http://lisp.jogger.pl/comment.php?eid=78513 ].
Hi drcode,
> Hi fellow LISPers, I have just slaved away at a new online tutorial for
> newbies or those with no previous LISP experience. (NObies? :-)
>
> http://www.lisperati.com
>
> (be sure to read the addendum at
> http://www.lisperati.com/addendum.html before suggesting any
> corrections...)
Bravo! Extraordinary!
One more thing we left out of the code is the defparameter command
for creating global variables- Instead, we just used setf to declare
variables (which works, but is considered bad style...)
While I understand this approach within a REPL style tutorial it would be
nice to see you fix the final code: <http://www.lisperati.com/code.html>
(that is replace each top-level setf with defparameter and add a comment
to the code explaining why you did this).
Regards,
Adam
On 5 Dec 2004 17:58:46 -0800, drcode wrote:
> Hi fellow LISPers, I have just slaved away at a new online tutorial for
> newbies or those with no previous LISP experience. (NObies? :-)
> http://www.lisperati.com
> Any feedback is greatly appreciated!
Please substitute "Lisp" for "LISP" throughout.
[And "Allegro Common Lisp" for "Allegro LISP", I guess]
--
If that makes any sense to you, you have a big problem.
-- C. Durance, Computer Science 234
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
<······@gmail.com> wrote in message
·····························@z14g2000cwz.googlegroups.com...
> Hi fellow LISPers, I have just slaved away at a new online tutorial for
> newbies or those with no previous LISP experience. (NObies? :-)
>
> http://www.lisperati.com
>
> (be sure to read the addendum at
> http://www.lisperati.com/addendum.html
> before suggesting any corrections...)
Innovative approach! Impressive and commendable! On a joking side note: does
the singular become .... "lisperatus"? :-)
And does that remind anyone of "Lisp errata" or is it only me? :-(
I do love the idea of casting SPELs. I agree that "macros" have become an
overloaded and banal word reminiscent of plain-vanilla Excel
breadcrumbs.....
Good job!
Panos C. Lekkas
Am 5 Dec 2004 17:58:46 -0800 schrieb <······@gmail.com>:
> http://www.lisperati.com
The Lisp Compiler is green!
http://www.lisperati.com/game_action.jpg
Oh, and I want that T-Shirt.
-ts
Old versions of Netscape (4.73 in particular)
don't supply missing </table> tags,
so the final paragraph, with the link to the next page,
doesn't get rendered.
For example
http://www.lisperati.com/syntax.html
is missing its final paragraph. Adding </table> to get:
<center>
<a href="index.html"><<
PREVIOUS</a>                 <a
href="data.html">NEXT >></a><br></center>
</table>
is enough to get the page to render.
Alan Crowe
Thanks Alan- I'm aware that if anyone tries to run my html through a
validator, they would have grounds to permanently ban me from the
internet. I'll be cleaning it up...
I'm not surprised - Anybody who tries to run my html through a
validator would have grounds to disqualify me from the Geneva
convention.
I'll do some cleanup in the near future to make sure its legal html...
-Conrad
I realize that anyone running my html through a validator has grounds
to disqualify me from the geneva convention. I will make the html valid
when I have some time...
-Conrad
This sucks- I posted these with the new google-groups and it told me
three times that it had failed to post the message and then an hour
later they suddenly *ALL* appeared...
Neat! My screen reader doesn't show the pictures, but thanks for the code
and explanations!
On Sun, 5 Dec 2004 ······@gmail.com wrote:
> Hi fellow LISPers, I have just slaved away at a new online tutorial for
> newbies or those with no previous LISP experience. (NObies? :-)
>
> http://www.lisperati.com
>
> (be sure to read the addendum at
> http://www.lisperati.com/addendum.html
> before suggesting any corrections...)
>
> The goal of this tutorial is twofold:
>
> 1. To take a non-LISP programmer along the straightest possible line so
> that he/she can appreciate some of the coolest, tastiest nuggets of
> programming power that LISP has to offer.
>
> 2. To explore the idea that Macros can be taught far more easily if
> they are given a different name, due to the semantic load present in
> this overused term. In my tutorial, I suggest the term SPEL as a simple
> synonym (replacement?) of "Macro" that offers many advantages for
> reasons outlined in the following essay:
>
> http://www.lisperati.com/no_macros.html
>
> Any feedback is greatly appreciated!
> --
> Conrad Barski, M.D. (concatenate 'string ·······@gm" "ail.com")
>
>
--