I understand that the LAMBDA macro (as opposed to lambda expressions)
was introduced somewhat late during the ANSI standardization. (I.e.
after CLTL2 anyway). What was the impetus for this addition?
Compatibility with existing dialects? Pure syntactic sugar? Something
else?
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@javamonkey.com> writes:
> I understand that the LAMBDA macro (as opposed to lambda
> expressions) was introduced somewhat late during the ANSI
> standardization. What was the impetus for this addition?
Kent posted about this a few times.
http://groups.google.com/groups?selm=sfwznlyx3y9.fsf%40shell01.TheWorld.com
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
Lars Brinkhoff wrote
> Kent posted about this a few times.
> http://groups.google.com/groups?selm=sfwznlyx3y9.fsf%40shell01.TheWorld.com
I've read that very lengthy post and was struck by
> The first thing they encounter is the weird syntax.
> That's usually strike one. Then the next thing they
> usually run into is defvar. That often becomes strike
> two. I don't know what strike three usually is because
> most newbies don't stick around c.l.l. long enough to let
> us know.
I was bitten on the arse by defvar. I needed 15 stitches and
a series of anti-rabies jabs. It really fucking hurt.
What I suggest is that text book writers should use a
steaming turd symbol to alert readers to hideous naming
errors.
defvar is such an innocent sounding name. Readers spot it in
a list of comands and skim the definition, only seeing what
they expect to see, and not spotting the horrible
implications of what is written. It is obvious from the name
what it does and how to use it. It's for defining variables,
init.
Well, no. References to defvar should always be along these
lines:
defvar HIDEOUSLY MISNAMED
Really
def-pervasive-special-while-preserving-prior-initialisation.
or
def-perv-noclobber
NOT a general purpose command!
Use it when your program lives in multiple files and has
multiple versions. For example
File A has (defvar *flag* 'complex)
File B has (defvar *flag* 'simple)
You build the simple version by loading file B.
Then you quit and start afresh.
You build the complex version by loading file A, followed
by file B. Although (defvar *flag* 'simple) was excuted
last, *flag* => complex, because defvar only evaluates its
value form if there is no prior initialisation.
See the hyperspec for other cunning and devious uses of this
cunning and devious command.
(Note to Peter Seibel: feel free to use this, without
attribution, and edited to your taste, in the book you are
working on)
Oh, strike three is compiled-function-p.
The point of compiled-function-p is to trick newbies into
thinking that they have compiled their code, when all they
have managed to do is to expand the macros. So the newbies
think that Lisp is terribly slow, running at interpreted
speeds even when compiled-function-p reassures them that
they are timing compiled code.
Alan Crowe
writing this standing up
From: Joe Marshall
Subject: Re: What was the impetus for the LAMBDA macro?
Date:
Message-ID: <7k3634u7.fsf@ccs.neu.edu>
> Lars Brinkhoff wrote
>> The first thing they encounter is the weird syntax.
>> That's usually strike one. Then the next thing they
>> usually run into is defvar. That often becomes strike
>> two.
Alan Crowe <····@cawNOtech.freeSPAMserve.co.uk> writes:
> Oh, strike three is compiled-function-p.
> The point of compiled-function-p is to trick newbies into
> thinking that they have compiled their code, when all they
> have managed to do is to expand the macros. So the newbies
> think that Lisp is terribly slow, running at interpreted
> speeds even when compiled-function-p reassures them that
> they are timing compiled code.
Strike 4: teachers and books that say
1) lisp is an interpreted-only language
2) is only used for AI applications
3) everything is a list
4) (DE PACK-IN (X) (COND ((ATOM X) X) ((EQ (CADR X) (QUOTE IN))
(READLIST (NCONC (EXPLODE (CAR X)) (NCONC (EXPLODE (QUOTE -IN-)) (EXPLODE (CADDR X))))))
((PRINT (CONS X (QUOTE ?))) (ERR)
)
)
)
Alan Crowe <····@cawNOtech.freeSPAMserve.co.uk> writes:
> I was bitten on the arse by defvar. I needed 15 stitches and
> a series of anti-rabies jabs. It really fucking hurt.
Yes, you have DEFVAR and DEFPARAMETER.
When you want DEFPARAMETER, you should not be using DEFVAR.
But then, not all my variables are DEFPARAMETER: you may need to keep
a value even when re-loading a file defining the variable that hold
it.
For example, load a pre-process a database in *MY-DATABASE*, then
oops, find a bug in the function you wanted to apply to the database.
With defvar, you'll be able to edit and re-load your sources and
continue from where you were without having to re-load and
re-pre-process the database.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
Pascal_Bourguignon explained:
> For example, load a pre-process a database in
> *MY-DATABASE*, then oops, find a bug in the function you
> wanted to apply to the database. With defvar, you'll be
> able to edit and re-load your sources and continue from
> where you were without having to re-load and
> re-pre-process the database.
Thanks Pascal. That is a nice example.
The hyper-spec is a model of clarity, hammering the point home at
http://www.lispworks.com/reference/HyperSpec/Body/m_defpar.htm#defvar
My concern is how do we avoid newbies being put off Lisp by
bad experiences with defvar. My ear training partner (its a
music thing) told me that he had programmed in CL and not
liked it. He specifically mentioned that "defvar worked
differently in compiled and interpreted code". Obviously he
had trusted the name, and never realised that he had to
check the specification to find out what was really going
on.
Names are enormously important. It is easy to imagine
some-one saying
I tried CL, but didn't like it because defvar didn't do
what I expected.
Many of us don't even have to imagine. But it is hard to
imagine some-one saying
I tried CL, but didn't like it because
def-perv-noclobber didn't do what I expected
Indeed picture this scene. Newbie does
(def-perv-noclobber var 'foo)
var => bar
So he starts writing his post to c.l.l. He tries to compose
a useful subject line, perhaps "Help, def-perv-noclobber
fails to change variable". At which point the penny
drops. It does say noclobber in the name. That sounds
suspicious. Where is the hyperspec?
But we are stuck with the name in the ANSI standard.
So what do we do? It is a tough question. My thoughts are
stimulated by re-reading The C Programming Language, by
Kernighan and Ritchie. They write
Similary, the order in which function arguments are
evaluated is not specified, so the statement
printf("%d %d\n", ++n, power(2, n)); /* WRONG */
can produce different results with different compilers
They continue in this vein for most of a page, so there is
no missing the point.
One unhappy situation is typified by the statement
a[i] = i++;
The question is whether the subscript is the old value of
i or the new....
And they end up drawing a moral. Quite the opposite from the
moral one might expect. Indeed, far from warning the reader
that this is quite the most hopeless language design
imaginable, and he should on no account program in C, K and
R actually wrap up the chapter like this:
The moral is that writing code that depends on order of
evaluation is a bad programming practice in any
language....
Hmm. Maybe there is a clue here. Is the way to make a
language popular in two parts:
1)Wave red flags round the warts in the language design,
so that programmers don't get caught out.
2)Bullshit that the bugs are features, and generally
just "Brass it out".
How should one spin defvar to help make CL more popular?
Perhaps like this
CL has really clever commands, such as
def-pervasively-special-variable-preserving-prior-initialisation
But don't worry about typing this in because we give
commands short friendly names. Like defvar. Then we put up
red flags round the short friendly names that name clever
commands that catch programmers out.
Alan Crowe
Alan Crowe <····@cawNOtech.freeSPAMserve.co.uk> writes:
> Pascal_Bourguignon explained:
> > For example, load a pre-process a database in
> > *MY-DATABASE*, then oops, find a bug in the function you
> > wanted to apply to the database. With defvar, you'll be
> > able to edit and re-load your sources and continue from
> > where you were without having to re-load and
> > re-pre-process the database.
>
> Thanks Pascal. That is a nice example.
> The hyper-spec is a model of clarity, hammering the point home at
>
> http://www.lispworks.com/reference/HyperSpec/Body/m_defpar.htm#defvar
>
> My concern is how do we avoid newbies being put off Lisp by
> bad experiences with defvar.
Perhaps newbies should be prevented to read CLHS. Or should be
prevented to program in Common Lisp before having read and memorized
the WHOLE CLHS.
But serriously, the page about DEFVAR in CLHS is exactly the same page
about DEFPARAMETER: they are described both at once, and the
difference is clear:
defparameter unconditionally assigns the initial-value to the
dynamic variable named name. defvar, by contrast, assigns
initial-value (if supplied) to the dynamic variable named name
only if name is not already bound.
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
> Perhaps newbies should be prevented to read CLHS. Or should be
> prevented to program in Common Lisp before having read and memorized
> the WHOLE CLHS.
>
> But serriously, the page about DEFVAR in CLHS is exactly the same page
> about DEFPARAMETER: they are described both at once, and the
> difference is clear:
It is the first of these two paragraphs that I take most
seriously. Computing is full of 1000 page
manuals. Programmmers are oppressed by deadlines. They
employ various heuristics to get stuff working by the
deadline, even though there is not enough time to read all
1000 pages. For example
defvar
defparameter
What leaps off the page is that it is not
defvariable
defparameter
nor is it
defvariable
defparam
The working programmer assumes that the language designer
knows all about deadline pressure and not having the time to
read 1000 pages before getting to work, and has quite
deliberately handed the working programmer a major clue.
defvar is the boring work-a-day one
defparameter has a clever twist to it
So the working programmer tries to optimise his path
throught the manual pages like this: punt on defvar, read
defmethod and defgeneric. Later read defpackage. Later still
go back and read defparameter.
Oh, and CL is lexically scoped by default, and that is good,
but just out of curiousity our newbie would like to know
what the commands are for creating dynamically scoped global
variables. It is not urgent. It is not what he actually
wants to do, so he is quite happy to leave searching for
them in the hyper spec until later :-P
Big manuals are not a problem.
Breaking the heuristics that programmers use to cope with big
manuals is a problem.
Alan Crowe
P.S. for any newbies reading this:
1)defvar and defparameter create special varibles
2)there are no commands built in to CL for creating global
lexical variables, you have to roll your own using
define-symbol-macro.
3)defvar, defparameter, and any setf's for which the REPL
gives you an automatic defvar trigger a backwards
compatibilty hack. They flip the affected symbol from
being lexically scoped by default, to being dynamically
scoped whether you want them to be or not. ie the
programmers deliberate ommision of (declare (special x))
gets overridden.
That is
(let ((x 'foo)); this x is special because the programmer
; asks for it to be special
(declare (special x))
(let ((x 'bar)) ; this x is lexical because the
; programmer didn't ask for it to
; be special
(symbol-value 'x))); this picks up the outer, special,
; binding
=> foo
(defvar x 'foo) ; This proclaims x to be special
; This does more than merely declaring it
; to be special
(let ((x 'bar)) ; Now all x's are special
; CL has no (declare (lexical x)) to turn
; this off
(symbol-value 'x)) ; So there are now two special
; variables, the inner one shadows
; the outer one as usual
=> bar
The standard work-around is (defvar *x*). That way you
only ruin the symbol *x* and can still make closures over
x's
4)This is an arcane issue that beginners can safely ignore.
The basic problem is that having a REPL to talk to makes
Lisp far to easy to learn. One can cease to be a beginner
after a couple of hours. One starts learning in the
morning and by the afternoon one is trying:
(let ((x 1000))
(defun linear(a b)
(+ (* a x) b)))
(mapcar #'linear '(1 2 3) '(4 5 6))
=> (1004 2005 3006)
This is no longer beginners stuff. If x was previously
defvar'ed this doesn't work
If you were learning C there would be no problem. You would
not be passing pointers to functions and using them with
linked lists until your second year of study.
* Alan Crowe wrote:
> Breaking the heuristics that programmers use to cope with big
> manuals is a problem.
`Programmers' whose heuristic for dealing with big manuals isn't `read
them, carefully' should be rendered down for pills and soap. If the
defining document for the language you want to use is too much for you
to read, then get a language with a smaller defining document (what do
you think Java is for?). If you can't read technical material at all,
you shouldn't be programming.
I mean, how big is the CL spec? 1000 pages? I forget. If you're
planning to program in CL, just sit down and read the bloody thing:
how long can it take - a week? If you are under such enormous
deadline pressure that you don't have time to read it then the
programs you will write will be crap anyway - hire someone who *has*
read it to write stuff, and you'll might get code that works.
Imagine if people treated, say, surgery, like they treated
programming: `Oh, I don't have time to find out about anatomy, I'll
just hack away because I have to meet my operation quota for the
week'. That's not even worthy to be called butchery - butchers spend
time learning their craft too, even though they don't require the
patient to survive.
I used to say that the state of programming was medieval, but that's
unfair to the middle ages - they knew a lot about learning craft
skills. Programmers are a bunch of spoilt children screaming that
they want things to work and they want them right now and no, they
don't want to put any effort into it at all, because mummy and daddy
do that for them, so they'll just scream thank you very much, because
that always works. Sooner or later, though, someone will lose
patience and drop them into the pot: pills and soap turn out to be the
best use for them.
--tim
Tim Bradshaw <···@cley.com> writes:
> Imagine if people treated, say, surgery, like they treated
> programming: `Oh, I don't have time to find out about anatomy, I'll
> just hack away because I have to meet my operation quota for the
> week'. That's not even worthy to be called butchery - butchers spend
> time learning their craft too, even though they don't require the
> patient to survive.
>
> I used to say that the state of programming was medieval, but that's
> unfair to the middle ages - they knew a lot about learning craft
> skills.
Yes, with companions journeying the country ten years before starting
to think they knew what their craft was about... But then, when what
you have to build is a cathedral that was started before you were born
and that will be finished after you die, we can't say you're under
deadline pressure...
--
__Pascal_Bourguignon__
http://www.informatimago.com/
Do not adjust your mind, there is a fault in reality.
Lying for having sex or lying for making war? Trust US presidents :-(
Newbies: do not read this material. If it is too late you are directed
to ignore it.
Tim Bradshaw wrote:
> * Alan Crowe wrote:
>
>>Breaking the heuristics that programmers use to cope with big
>>manuals is a problem.
>
>
> `Programmers' whose heuristic for dealing with big manuals isn't `read
> them, carefully' should be rendered down for pills and soap. If the
> defining document for the language you want to use is too much for you
> to read, then get a language with a smaller defining document (what do
> you think Java is for?).
Oh, my. You know Java is a programming language, yes? And that (I get
your point) as simple as it is, you really cannot do anything with it
until you /also/ learn huge libraries. I think you meant to refer them
to Scheme.
> If you can't read technical material at all,
> you shouldn't be programming.
OK, bartending school it is. I spend all my time there anyway, might as
well get paid for it. And then the bouncers are on /my/ side.
>
> I mean, how big is the CL spec? 1000 pages? I forget.
You forget? No problem:
http://www-2.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/FrontMatter/About-HyperSpec.html#Trivia
<ROFL>
Hopefully I got to you before had hand-counted all the pages of the book
one by one.
>
> Imagine if people treated, say, surgery, like they treated
> programming: `Oh, I don't have time to find out about anatomy, I'll
> just hack away because I have to meet my operation quota for the
> week'. That's not even worthy to be called butchery - butchers spend
> time learning their craft too, even though they don't require the
> patient to survive.
Oh, goody! Argument by analogy!! These always resolve disputes quickly.
By your analogy, the way I program, I must have a thousand patients
buried in my backyard considering the way I learned programming. Bzzzt!
Here's mine: imagine someone learning to walk by reading the manual.
They are still on their asses, because no one knows how we walk. Gee,
how /do/ we learn how to walk?
>
> I used to say that the state of programming was medieval, but that's
> unfair to the middle ages - they knew a lot about learning craft
> skills. Programmers are a bunch of spoilt children screaming that
> they want things to work and they want them right now and no, they
> don't want to put any effort into it at all, because mummy and daddy
> do that for them, so they'll just scream thank you very much, because
> that always works.
"When I find something that works for me, I stick with it."[1]
> Sooner or later, though, someone will lose
> patience and drop them into the pot: pills and soap turn out to be the
> best use for them.
Having run all the above backwards through my Bradshaw 2000 Hyperbolizer
and come up with "look it up".... I agree.
kenny
[1] John Candy in "Splash" when caught in his boyhood practice of
deliberately dropping change on the ground so he could look up girls'
skirts while picking it up.
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
* Kenny Tilton wrote:
> Here's mine: imagine someone learning to walk by reading the
> manual. They are still on their asses, because no one knows how we
> walk. Gee, how /do/ we learn how to walk?
You do it by practising. But you don't blame gravity when you fall
over. Similarly you learn programming by practising and reading. In
particular you *make some effort to learn what an operator does before
you use it*. That means *read the documentation*, for instance.
I once shared a house with someone who was learning the violin. The
noises were fairly painful. But he didn't blame the violin for that,
he blamed his lack of skill - correctly. And he understood, because
he could already play the piano pretty well, that learning the violin
wasn't something you did in a week. It's taken me 25 years to learn
to play the guitar, so far, and I still get better from week to week.
I'll be a rock god yet. And strangely, the things that bugged me for
ages and ages - that wound strings sound different than unwound
meaning you get inevitable sudden changes of tone, that the instrument
is inherently friendlier to some keys than others, and so on - are
things I'd now never want to change because they turn out to be
features.
Eventually, you might get good enough to want to change the language
or to realistically make some improvements to the instrument. For
languages with a lot of development like CL this will not be very
quickly. (I've been using CL for 15 years and I have some tentative
ideas on things that could be done to defpackage, most of which are
implementable within the current language anyway. But I'm not sure
they're good ideas yet: I've only been thinking about them for a
couple of years.). For instruments like violins which have had
hundreds of years of development it will almost certainly be
never. (Even for electric guitars, I can't think of an easy way to
improve on the instrument I have, which could have been made in the
early 50s. Actually, if it had been made in the 50s it would probably
sound better, and I'd also be rich.)
Complaining about the names of operators is generally just
time-wasting by beginners who can't, or won't read - think how stupid
the I-hate-car/cdr people sound to an experienced Lisp person. car,
cdr and defvar are *just words in the language*, and they no more need
changing than does `magdeline'. Yes, you have to know how to
pronounce it and that its pronunciation is context-dependent (and I
can't even remember if both the Oxford & Cambridge colleges pronounce
it the same way), but it doesn't need fixed, if only because no one
wants to have gone to maudlin college.
For God's sake, if you want to complain, complain about defun: what
are these `un' things that it's defining? Is this some fiendish plot
by communist Lisp hackers to challenge the US's God-given right to
blow the hell out of whom we please by secretly infiltrating all our
programs with references to godless communist organisations run by
people who make cheese that tastes of something? Damn, I knew those
MIT people were commies. They probably like cheese too.
Or maybe just read the manual and learn how it works. It takes more
than 21 days to become competent at anything, it really does.
--tim
(If you *really* want to complain, complain about the syntax of
restart-case: isn't it just really awkward with all those weird
keywords in the middle? But I'm not sure I could make it better.)
> cdr and defvar are *just words in the language*, and they no more need
> changing than does `magdeline'. Yes, you have to know how to
> pronounce it and that its pronunciation is context-dependent (and I
> can't even remember if both the Oxford & Cambridge colleges pronounce
> it the same way), but it doesn't need fixed, if only because no one
> wants to have gone to maudlin college.
>
The pronunciation is different Oxford says 'maudlen' [phonetic sound],
Cambridge uses the more common 'magdalen' pronunciation, (which is also how
it is spelled).
Rmagere wrote:
>
> The pronunciation is different Oxford says 'maudlen' [phonetic sound],
> Cambridge uses the more common 'magdalen' pronunciation, (which is also how
> it is spelled).
Nope. It's 'maudlen' (or possibly 'maudlin') here in Cambridge too.
I have no idea what this has to do with lisp.
Tom
Tom Evans wrote:
> Nope. It's 'maudlen' (or possibly 'maudlin') here in Cambridge too.
Thanks for the corrections as many people in Oxford carry that
misconception.
> I have no idea what this has to do with lisp.
None (hence the Off Topic tag attached to the Subject of the message), but
the fact
that Tim Bradshaw brought it up in some analogy.
Rmagere wrote:
>
> Tom Evans wrote:
> > Nope. It's 'maudlen' (or possibly 'maudlin') here in Cambridge too.
> Thanks for the corrections as many people in Oxford carry that
> misconception.
I suspect there are many myths about each other bigger than that one...
> > I have no idea what this has to do with lisp.
> None (hence the Off Topic tag attached to the Subject of the message), but
> the fact
> that Tim Bradshaw brought it up in some analogy.
I was only joking actually. I should have made that clearer.
* Tom Evans wrote:
> I have no idea what this has to do with lisp.
There are strange, often irrational, historical artifacts in English,
and in CL. This doesn't say anything bad about either language:
they're just the way they are. It's tempting, especially if you're
desperately trying to avoid the awful truth that you can't write
English or program in CL very well, to rail against these oddities as
if they were something that, somehow, prevented you from writing
English, or programming. Cll is full of people doing just this. But
the curious names of some operators in CL don't prevent you from
programming - maybe they mean you have to read the manual, but you
shouldn't be programming if you are not willing to read manuals - any
more than the oddities of English prevented Shakespeare from writing.
Finally, I'm fairly sure that the people who *do* make successful
changes to languages are those who are most fluent in them, not
beginners Shakespeare and the authors of the King James Bible changed
English forever. Jimi Hendrix changed the way the electric guitar
would be played forever.
Yes, this is elitist: the good news is that the way to become elite
(if you don't have a BBC micro) is substantially practice. The bad
news is that that's the only way: even prodigies practice. In fact
one thing that distinguishes prodigies is their ability to practice
for more hours a day than the rest of us.
--tim
Tim Bradshaw <···@cley.com> writes:
> English forever. Jimi Hendrix changed the way the electric guitar
> would be played forever.
Oh, come on! You're not telling me he was a prodigy: he couldn't even
play it the right way up ...
-dan
--
http://web.metacircles.com/cirCLe_CD - Free Software Lisp/Linux distro
>>>>> "Tim" == Tim Bradshaw <···@cley.com> writes:
Tim> the way to become elite (if you don't have a BBC micro) is
Tim> substantially practice.
Even with a BBC micro substantial amounts of practice is needed.
On the other hand, acquiring practice is now possible on contemporary
hardware.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Tom Evans wrote:
> Rmagere wrote:
>
> > The pronunciation is different Oxford says 'maudlen' [phonetic sound],
> > Cambridge uses the more common 'magdalen' pronunciation, (which is also how
> > it is spelled).
>
> Nope. It's 'maudlen' (or possibly 'maudlin') here in Cambridge too.
In full gory detail:
- Oxonienses and Cantabrigienses pronounce it the same way.
- But we *spell* it differently.
- Neither group spells it the way Tim did. :-)
Oxford spelling: Magdalen.
Cambridge spelling: Magdalene.
We also have different numbers of queens. (One in Oxford,
more than one in Cambridge.)
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
> Oxford spelling: Magdalen.
> Cambridge spelling: Magdalene.
Presumably the Cambridge spelling is longer because
they are `can't abridge ians'.
Tim Bradshaw <···@cley.com> wrote in message news:<···············@cley.com>...
[snippage]
Can I quote you on some of this? Specifically, there's a couple
of lines in here that I think would go GREAT in a fortune file. I
would, of course, provide proper attribution (and only with
permission). The lines in question are:
> `Programmers' whose heuristic for dealing with big manuals isn't `read
> them, carefully' should be rendered down for pills and soap.
and:
> I used to say that the state of programming was medieval, but that's
> unfair to the middle ages - they knew a lot about learning craft
> skills.
Not only funny, but very true. I think you might be channelling
the spirit of Djkstra there. :-)
Avi Blackmore
Avi Blackmore approves of Tim Bradshaw's line
>> `Programmers' whose heuristic for dealing with big manuals isn't `read
>> them, carefully' should be rendered down for pills and soap.
"Read the documentation" is the conventional wisdom, but
you might wish to spend a while reading the documentation
before you decide how heavily you wish to commit to this
creed.
Take a look at
http://www.lispworks.com/reference/HyperSpec/Body/s_if.htm
http://www.lispworks.com/reference/HyperSpec/Body/m_defpar.htm
I've excerpted a few key lines:
if test-form expression [expression] => result*
defparameter name expression [documentation] => name
defvar name [expression [documentation]] => name
Or have I? Did I lightly edit those three lines? Perhaps the
originals read:
if test-form then-form [else-form] => result*
defparameter name initial-value [documentation] => name
defvar name [else-form [documentation]] => name
In all the best fairy-stories, the hero has a choice of
three answers to the riddle, so here is version number three:
if test-form then-form [else-form] => result*
defparameter name initial-value [documentation] => name
defvar name [initial-value [documentation]] => name
And the riddle is this:
Which of these three versions best supports the
suggestion that one reading the manual carefully.
In all the best fairy-stories, the hero faces a trick
question, so take a while to type at your REPL and make sure
that you understand the functionality that the specification
attempts to capture in words.
(if t (progn (print "doing sum")(+ 2 2))
(progn (print "consing") (cons 'a 'b)))
=>
"doing sum"
4
(if nil (progn (print "doing sum")(+ 2 2))
(progn (print "consing") (cons 'a 'b)))
=>
"consing"
(A . B)
(defparameter *test*
(progn (print "doing sum")(+ 2 2)))
=>
"doing sum"
*TEST*
(defparameter *test*
(progn (print "consing") (cons 'a 'b)))
=>
"consing"
*TEST*
(defvar *trial* (progn (print "doing sum")(+ 2 2)))
=>
"doing sum"
*TRIAL*
(defvar *trial*
(progn (print "consing") (cons 'a 'b)))
=>
*TRIAL*
Well, which of the three is best? Be sure to explain your
reasoning.
We might get interested programmers to stick to Lisp by
boiling them down for glue, but we will have more success
getting them to persevere with Lisp if we focus our energies
on polishing our documentation to make it shiny and attractive.
Alan Crowe
Alan Crowe wrote:
> "Read the documentation" is the conventional wisdom, but
> you might wish to spend a while reading the documentation
> before you decide how heavily you wish to commit to this
> creed.
[ the rest deleted ]
Did you actually have a point you were trying to make?
Paul
Paul asked:
> Did you actually have a point you were trying to make?
Yes, pleae grant me 1minute 20seconds. The topic is:
"how do we make Lisp more popular."
Erann Gat suggested that we are losing some potential
Lispers when they have a bad time with defvar. This chimed
with my experience and that of a friend, who was indeed put
off Lisp by defvar.
The background I assume is that we are all familiar with the
way that information trickles down, via cutting and pasting,
from specifications, to text books, to popularisations and
ends up on quick reference cards stuck in their end papers.
So I picture the scene. A potential Lisper is sitting at a
REPL, mug of coffee in one hand, quick reference card in the
other. We have until his coffee goes cold to win him for
Lisp. As a community, we control what is on that quick
reference card, because we write the top level of documents
from which it descends. My point is that we want it to read
if test-form then-form [else-form] => result*
defparameter name initial-value [documentation] => name
defvar name [else-form [documentation]] => name
I don't know that I'm right, but I know that this discussion
matters, because persons who try Lisp and don't like it tell
us that defvar matters.
Alan Crowe
Alan Crowe wrote:
> ...
>
> I don't know that I'm right, but I know that this discussion
> matters, because persons who try Lisp and don't like it tell
> us that defvar matters.
there is no need to conjecture. if you are convinced that this would matter,
then write the reference card, publish it, and see who uses it. do not let it
stop you, that the last reference card i can recall trusting was for os360
assember. i might well be one of the first people to download yours to see if
it says anything useful.
...
* Alan Crowe wrote:
> So I picture the scene. A potential Lisper is sitting at a
> REPL, mug of coffee in one hand, quick reference card in the
> other.
So let's see. That's a quick reference card to a language with over
900 defined symbols, I take it. What makes us believe that the right
way to learn a language this size is with a quick reference card,
while the right way to learn, say, an engineering discipline, is with
textbooks? Do you expect someone would learn to, say, turn things on
a lathe by using a quick reference card? Why? Why are programming
languages *so much easier* than practically everything else we do.
No, it's OK, don't answer. Obviously I have some strange
old-fashioned ideas that people might, well, read manuals (or that
they might use environments where they have easy access to the
hyperspec and *look it up*, for instance. But no, they just use
defvar because they *know* what it does already).
I'll go back to my cave.
--tim
Tim Bradshaw wrote:
> So let's see. That's a quick reference card to a language with over
> 900 defined symbols, I take it. What makes us believe that the right
> way to learn a language this size is with a quick reference card,
> while the right way to learn, say, an engineering discipline, is with
> textbooks? Do you expect someone would learn to, say, turn things on
> a lathe by using a quick reference card? Why? Why are programming
> languages *so much easier* than practically everything else we do.
>
Hi, I am not going to debate whether it's right or not to assume that
people should read the entire manual of a programming language,
however I would like to argue that one of the reasons that some people
would like to just use a "reference card" to achieve most of their
programming
needs (while not striving to achieve mastery of the language) is that a lot
of
people with no intentions of becoming programmers might have at different
times in their life the need to write bits of codes to make their life
easier or to
do some research etc.
How many people really have the need (or actual wish) to be able to design a
chemical plant? or to use a lathe for that matter? Instead nowadays with
computers as pervasive in everyday life more people fill the need to be able
to do
more with them.
I think that the issue here is that this problem can be seen from two main
point of
views:
a) Software Programmer --> who strikes to achieve mastery of the language
and
hopefully also of writing beautiful code (whatever your definition of
beautiful is)
b) Random User --> who just want to write some code that does something he
feels the need for (something small or smallish) and that writes mainly for
himself
and hence would rather avoid having to put too much effort into learning a
language
It's a bit like English (or any other spoken language) not everybody wants
to be
able to write best-sellers or classics, however everybody (or almost) feels
the need
to be able to communicate.
Rmagere
P.S. I do agree that at least looking up a function on the hyperspec if it's
the first time
it's used should be a requirement, just like you would check for a new word
on a
dictionary.
Rmagere writes:
> Hi, I am not going to debate whether it's right or not to assume that
> people should read the entire manual of a programming language,
> however I would like to argue that one of the reasons that some people
> would like to just use a "reference card" to achieve most of their
> programming
> needs (while not striving to achieve mastery of the language) is that a lot
> of
> people with no intentions of becoming programmers might have at different
> times in their life the need to write bits of codes to make their life
> easier or to
> do some research etc.
If those with no intentions of becoming programmers, and rely on
reference cards, are the same who use Windows/Outlook and can't even
check that their system doesn't spread worms everywhere[*], I hope
that I will never have to deal with their code.
Paolo
[*] During the peak of the latest worm, I got up to 4-500 worm
messages per day.
--
Paolo Amoroso <·······@mclink.it>
Alan Crowe wrote:
>
> ...
>
> "Read the documentation" is the conventional wisdom, but
> you might wish to spend a while reading the documentation
> before you decide how heavily you wish to commit to this
> creed.
>
> Take a look at
>
> http://www.lispworks.com/reference/HyperSpec/Body/s_if.htm
> http://www.lispworks.com/reference/HyperSpec/Body/m_defpar.htm
>
> I've excerpted a few key lines:
>
> ...
> Or have I? Did I lightly edit those three lines? Perhaps the
> originals read:
>
> ...
>
> In all the best fairy-stories, the hero has a choice of
> three answers to the riddle, so here is version number three:
>
> ...
>
> And the riddle is this:
>
> Which of these three versions best supports the
> suggestion that one reading the manual carefully.
>
and, as riddles sometimes go, the answer is not to be found in the problem as
set. in that, actually, none of them do. to my best knowledge, however,
k.pitman has a rather good command of the english language in addition to his
ability to formulate abstract syntax. at least that has been my experience. in
accord with which, i tend to read the english text which explains the abstract
syntax. especially if the abstract syntax contains terms or combinations the
meaning of which are not immediately evident. in the case of the
defparameter,defvar entry i have never found the description lacking.
yes, i have also had occasion to change a defvar definition to a defparameter,
but i've tended to see them as my bug. my only argument has been with the
standard, in that it does not provide a means to document an unbound variable,
but that's a separate issue.
...
james anderson <··············@setf.de> writes:
> yes, i have also had occasion to change a defvar definition to a defparameter,
> but i've tended to see them as my bug. my only argument has been with the
> standard, in that it does not provide a means to document an unbound variable,
> but that's a separate issue.
(defvar *foo*)
(setf (documentation '*foo* 'variable) "documentation")
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes wrote:
>
> james anderson <··············@setf.de> writes:
>
> > yes, i have also had occasion to change a defvar definition to a defparameter,
> > but i've tended to see them as my bug. my only argument has been with the
> > standard, in that <em>it</em> does not provide a [direct] means to document an unbound variable,
----------------------^^^^^^^^^^^
> > but that's a separate issue.
>
> (defvar *foo*)
> (setf (documentation '*foo* 'variable) "documentation")
in keeping with which i have, on occasion, relied on a macro, handy things
that they are, to enforce an even more draconic interpretation of the riddle,
to wit:
(defMacro defUnboundVar (name &optional documentation)
`(prog1 (defVar ,name)
(makunbound ',name)
#+Genera(declaim (special ,name))
,@(when documentation
`((setf (documentation ',name 'variable) ,documentation)))))
...
From: ·············@comcast.net
Subject: Re: DEFVAR vs. DEFPARAMETER
Date:
Message-ID: <k7727i3s.fsf@comcast.net>
stUdlIfIed Code but All lowErcAsE pOstinG?
james anderson <··············@setf.de> writes:
> in keeping with which i have, on occasion, relied on a macro, handy things
> that they are, to enforce an even more draconic interpretation of the riddle,
> to wit:
>
> (defMacro defUnboundVar (name &optional documentation)
> `(prog1 (defVar ,name)
> (makunbound ',name)
> #+Genera(declaim (special ,name))
> ,@(when documentation
> `((setf (documentation ',name 'variable) ,documentation)))))
>
> ...
i am curious as tO why YoU uNcoNditioNally call `maKunbOund'. That
sEeMs very `dEfpArAmEtErIsh'.
ThE one i UsE is This:
(defmacro defvar-unbound (variable-name documentation)
"Like DEFVAR, but the variable will be unbound rather than getting an initial value.
This is useful for variables which should have no global value but might have a
dynamically bound value."
`(EVAL-WHEN (:LOAD-TOPLEVEL :COMPILE-TOPLEVEL :EXECUTE)
(DEFVAR ,variable-name)
(SETF (DOCUMENTATION ',variable-name 'VARIABLE)
,documentation)))
since i doN't studliFy my Code, i can UsE case tO diStinGuiSh thE TemPlaTe
From thE `holes'.
DE gusTibus nOn DisPuTanDum esT.
·············@comcast.net wrote:
>
> stUdlIfIed Code but All lowErcAsE pOstinG?
>
> james anderson <··············@setf.de> writes:
>
> > in keeping with which i have, on occasion, relied on a macro, handy things
> > that they are, to enforce an even more draconic interpretation of the riddle,
> > to wit:
> >
> > (defMacro defUnboundVar (name &optional documentation)
> > `(prog1 (defVar ,name)
> > (makunbound ',name)
> > #+Genera(declaim (special ,name))
> > ,@(when documentation
> > `((setf (documentation ',name 'variable) ,documentation)))))
> >
> > ...
>
> i am curious as tO why YoU uNcoNditioNally call `maKunbOund'. That
> sEeMs very `dEfpArAmEtErIsh'.
>
well, that's 'cause it's a variation on defVar.
in the context of the earlier "riddle" post, it serves to illustrate that the
abstract syntax cannot be expected to explain everything. in this case, the
behaviour when there is no initial-value. it implements one of the semantics
which i had actually considered that defvar might have had - until i had read
further down the page.
> ThE one i UsE is This:
>
> (defmacro defvar-unbound (variable-name documentation)
> "Like DEFVAR, but the variable will be unbound rather than getting an initial value.
> This is useful for variables which should have no global value but might have a
> dynamically bound value."
> `(EVAL-WHEN (:LOAD-TOPLEVEL :COMPILE-TOPLEVEL :EXECUTE)
> (DEFVAR ,variable-name)
> (SETF (DOCUMENTATION ',variable-name 'VARIABLE)
> ,documentation)))
>
> since i doN't studliFy my Code, i can UsE case tO diStinGuiSh thE TemPlaTe
> From thE `holes'.
yes, one can. although, given such an adret pinky, i'm surprised that it puts
up with the constraint.
i try to stick to just the first character of successor syllables in macro
operators only. i understand that many prefer orthographic conventions like
define-variable-unbound, but my somewhat prejudical view is that a name like
define-method-combination was a poor choice and that a clear orthographic
distinction between hyphenated names, for functions - which do argument
evaluation, and abbreviated names, for macros - which do not, can make it
easier to predict what to expect from foreign code on an initial reading.
whereby the selective capitalization aids the reader in the case of longer
"abbreviations". i observe this even for code which i myself wrote, which can
appear somewhat foreign as the decades pass. but, as you note,
>
> DE gusTibus nOn DisPuTanDum esT.
...
From: ·············@comcast.net
Subject: Re: DEFVAR vs. DEFPARAMETER
Date:
Message-ID: <he265edd.fsf@comcast.net>
james anderson <··············@setf.de> writes:
> ·············@comcast.net wrote:
>>
>> since i doN't studliFy my Code, i can UsE case tO diStinGuiSh thE TemPlaTe
>> From thE `holes'.
>
> yes, one can. although, given such an adret pinky, i'm surprised that it puts
> up with the constraint.
I fool it by typing it normally and then going back and using meta-u
on the appropriate sections. It's none the wiser.
You make some good points and I hope you find that I have
responded in the total rewrite of my post with which I have
answered Paul F. Dietz's question.
Alan Crowe
Tim Bradshaw diplomatically insinuated that
> `Programmers' whose heuristic for dealing with big manuals
> isn't `read them, carefully' should be rendered down for
> pills and soap.
Remember that I'm feeding your cat next week. You cannot
rendered me down for pills and soap until Thursday.
Back to programming. Is the branch cut of sqrt on the
negative real axis, or the negative imaginary axis? Maybe
it is programable. Perhaps I have to write (sqrt x 180) or
(sqrt x 270) or (sqrt x -pi). I'll check the hyperspec.
No wait, I'm being rendered down for pills and soap on
Thursday. I don't have time. I'll just trust that the branch
cut is in the usual place.
Alan Crowe
* Alan Crowe wrote:
> No wait, I'm being rendered down for pills and soap on
> Thursday. I don't have time. I'll just trust that the branch
> cut is in the usual place.
You shouldn't be programming if you only have a week to learn the
language and write the program. That was the point.
--tim
Tim Bradshaw wrote:
> * Alan Crowe wrote:
>
>
>>No wait, I'm being rendered down for pills and soap on
>>Thursday. I don't have time. I'll just trust that the branch
>>cut is in the usual place.
>
>
> You shouldn't be programming if you only have a week to learn the
> language and write the program. That was the point.
OK, but we're trying to grow this language, which is so eminently
approachable because of the REPL and Hyperspec. And really, any language
is approachable, tho in most cases your dialog is with the compiler as
it repeatedly rejects ones syntax.
In the past we have heard newbies here commanded to sit down for days
and read the spec front to back. Could we please not make it sound as if
there is some problem with CL that makes it necessary to study a
thousand pages before starting on it?
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Kenny Tilton <·······@nyc.rr.com> writes:
[SNIP]
> In the past we have heard newbies here commanded to sit down for days
> and read the spec front to back. Could we please not make it sound as
> if there is some problem with CL that makes it necessary to study a
> thousand pages before starting on it?
There isn't. However, having read the relevant documentation before
one delivers applications or whenever one spots something that is
counter-intuitive is heartily recommended.
//Ingvar
--
((lambda (x) `(,x ',x)) '(lambda (x) `(,x ',x)))
Probably KMP
* Ingvar Mattsson wrote:
> There isn't. However, having read the relevant documentation before
> one delivers applications or whenever one spots something that is
> counter-intuitive is heartily recommended.
Exactly.
And actually, I'm really not sure we do want to attract the kind of
people who aren't willing to expend some effort to learn a language.
Not just to CL, to programming. They *will* produce code that doesn't
work, whether they write in Lisp or in C. Lisp's biggest problem,
along with other high-level languages, is that these people can get
further than they can in C - in C the serious losers will find that
anything they write that's more than a few lines will die of pointer
plague, in Lisp these people have to wait for something like defvar
doing something `strange', and that's further down the line.
Attracting these people will result in yet more crap, insecure,
unmaintainable code, and that's the last thing we need. Worse, since
essentially all mundane programming is going to be outsourced to India
and China in the next 10-20 years, we're just creating a lot of people
who will become unemployed in due course.
--tim
>>>>> "AC" == Alan Crowe <····@cawNOtech.freeSPAMserve.co.uk> writes:
[...]
AC> So the working programmer tries to optimise his path throught
AC> the manual pages like this: punt on defvar, read defmethod and
AC> defgeneric. Later read defpackage. Later still go back and
AC> read defparameter. [...]
I agree with the spirit of this in the descriptive sense, but surely
if a programmer has to read about defmethod and defgeneric under
deadline pressure then he's taken on a project as a language newbie.
Sucess will surely follow form that.
cheers,
BM
Pascal Bourguignon <····@thalassa.informatimago.com> writes:
> Perhaps newbies should be prevented to read CLHS. Or should be
> prevented to program in Common Lisp before having read and memorized
> the WHOLE CLHS.
I know you were tongue in cheek, but, really, this is
_precisely_ the most important thing we should teach
newbies: that programming is a matter of precision
and exactitude; that they should leave their assumptions
at home, that the Common Lisp spec is the best and most
precise language specification they are likely to find,
and that they SHOULD READ UP on any form they do not
already know.
Note that, by definition, if you're a newbie, you don't know any
forms, so you should read up on everything before using it.
One of the big problems with this industry, IMO, is the
persistent lie that things "ought to be easy". That's why
we end up with things like C++ and Java; so noone has to
learn new syntax (too hard), don't want to make anyone
feel "uncomfortable".
--ap (feeling grumpy today)
Alain Picard wrote:
> Pascal Bourguignon <····@thalassa.informatimago.com> writes:
>
>
>>Perhaps newbies should be prevented to read CLHS. Or should be
>>prevented to program in Common Lisp before having read and memorized
>>the WHOLE CLHS.
>
...
> and that they SHOULD READ UP on any form they do not
> already know.
>
> Note that, by definition, if you're a newbie, you don't know any
> forms, so you should read up on everything before using it.
Nah, this is Lisp. Just go to the Listener and type it in, see what
happens. Read up on something only if you get stuck. Next stop: The
Savages of CLL.
:)
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Kenny Tilton <·······@nyc.rr.com> writes:
> Alain Picard wrote:
>> Pascal Bourguignon <····@thalassa.informatimago.com> writes:
>>
>>>Perhaps newbies should be prevented to read CLHS. Or should be
>>>prevented to program in Common Lisp before having read and memorized
>>>the WHOLE CLHS.
>>
> ...
>
>> and that they SHOULD READ UP on any form they do not
>> already know.
>> Note that, by definition, if you're a newbie, you don't know any
>> forms, so you should read up on everything before using it.
>
> Nah, this is Lisp. Just go to the Listener and type it in, see what
> happens. Read up on something only if you get stuck. Next stop: The
> Savages of CLL.
If that fails, just make up something you think is plausible
and insist that everyone do it that way.
Kenny Tilton <·······@nyc.rr.com> writes:
> Nah, this is Lisp. Just go to the Listener and type it in, see what
> happens. Read up on something only if you get stuck.
No. Common Lisp is not like the other "one-implementation"
languages, where the REPL will tell you the truth. CL
has several implementations, and some of them (all of them?)
have bugs.
Common Lisp is defined by a document, not by an implementation.
Alain Picard <·······················@optushome.com.au> writes:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
> > Nah, this is Lisp. Just go to the Listener and type it in, see what
> > happens. Read up on something only if you get stuck.
>
> No. Common Lisp is not like the other "one-implementation"
> languages, where the REPL will tell you the truth. CL
> has several implementations, and some of them (all of them?)
> have bugs.
>
> Common Lisp is defined by a document, not by an implementation.
True enough. But I have a confession to make:
I am a long-time Lisp user and I often use the REPL method when
wondering how a particular case will be handled.
It may be a bit of laziness, but all implementations get almost all of
the language right, so it tends to work in practice. If it is something
critical, or if the results of the trying it seem odd, I will then
consult the Spec.
In any case, as a practical matter, I still need to know how the
implementations of Lisp I use handle the code, even if they do it
incorrectly. If they are incorrect, then I need to handle that as
well.
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> In any case, as a practical matter, I still need to know how the
> implementations of Lisp I use handle the code, even if they do it
> incorrectly. If they are incorrect, then I need to handle that as
> well.
I hope that part of the handling of incorrect implementations involves
submitting bug reports to the maintainers of the implementation, and
also that the inevitable *features* conditionalization that is
included in your source is robust to the bug being fixed.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> writes:
>
> ···@sevak.isi.edu (Thomas A. Russ) writes:
>
> > In any case, as a practical matter, I still need to know how the
> > implementations of Lisp I use handle the code, even if they do it
> > incorrectly. If they are incorrect, then I need to handle that as
> > well.
>
> I hope that part of the handling of incorrect implementations involves
> submitting bug reports to the maintainers of the implementation, and
> also that the inevitable *features* conditionalization that is
> included in your source is robust to the bug being fixed.
I try to. Actually, get the conditionalization right isn't all that
easy either. A lot of Lisps make a sort of monotonicity assumption and
include all the previous version numbers. (I mean, the implementation
only gets better, so what worked in version 2.2 works in version 3.0 as
well, doesn't it?)
The most robust technique that I've run across (thanks to Hans Chalupsky
for showing this to me) is actually to implement my own features and use
a test which identifies the bug or non-conformance or just difference to
set the feature before loading the conditionalized code.
One interesting place this happened recently was discovering that
READ-LINE under MCL does not return a SIMPLE-STRING. (The standard
doesn't require it). This blew up some of our code, until we realized
that we couldn't make this assumption. (Actually we wrapped the call in
MCL so that we could.)
--
Thomas A. Russ, USC/Information Sciences Institute
···@sevak.isi.edu (Thomas A. Russ) writes:
> I try to. Actually, get the conditionalization right isn't all that
> easy either. A lot of Lisps make a sort of monotonicity assumption and
> include all the previous version numbers. (I mean, the implementation
> only gets better, so what worked in version 2.2 works in version 3.0 as
> well, doesn't it?)
:-) This is indeed a problem. Some, ahem, older-style code breaks
each time CMUCL makes a new release, for instance, and some others
contain workarounds for bugs fixed 5 year ago...
> The most robust technique that I've run across (thanks to Hans Chalupsky
> for showing this to me) is actually to implement my own features and use
> a test which identifies the bug or non-conformance or just difference to
> set the feature before loading the conditionalized code.
Agreed. I use something like the following, early in the build of my
systems:
(in-package "FOO-INT")
(eval-when (:compile-toplevel :execute)
(when (find-symbol "PACKAGE-LOCKS" "EXT")
(pushnew 'foo-build:package-locks *features*)))
#+foo-build:package-locks
(eval-when (:load-toplevel)
(unless (find-symbol "PACKAGE-LOCKS" "EXT")
(error "binary incompatibility: code compiled with ~S, but the ~
functionality doesn't exist in the running lisp."
'foo-build:package-locks)))
The idea behind this style of conditionalization is that it works both
forward- and backward-compatibly (unless, of course the interface to
package locks is changed).
> One interesting place this happened recently was discovering that
> READ-LINE under MCL does not return a SIMPLE-STRING. (The standard
> doesn't require it). This blew up some of our code, until we realized
> that we couldn't make this assumption. (Actually we wrapped the call in
> MCL so that we could.)
There are some surprising (transitory and not-so-) bugs in released
versions of software... I suppose I shouldn't be /that/ surprised,
given my observation from too close of Paul Dietz's test suite... from
sbcl's src/cold/ansify:
;;;; CMUCL issues
#+cmu
(progn
(warn "CMU CL has a broken implementation of READ-SEQUENCE.")
(pushnew :no-ansi-read-sequence *features*))
#+(and cmu alpha)
(unless (ignore-errors (read-from-string "1.0l0"))
(error "CMUCL on Alpha can't read floats in the format \"1.0l0\". Patch your c
ore file~%~%"))
#+(and cmu sparc)
(ext:set-floating-point-modes :traps '(:overflow :invalid :divide-by-zero))
;;;; OpenMCL issues
#+openmcl
(unless (ignore-errors (funcall (constantly t) 1 2 3))
(error "please find a binary that understands CONSTANTLY to build from"))
(It should be said that I don't believe that the first CMUCL test
there is currently relevant, unless running a fairly long-in-the-tooth
version. However, given the :no-ansi-read-sequence workaround exists,
it's probably easier to use it than to develop elaborate testing
code...)
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Alain Picard wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Nah, this is Lisp. Just go to the Listener and type it in, see what
>>happens. Read up on something only if you get stuck.
>
>
> No. Common Lisp is not like the other "one-implementation"
> languages, where the REPL will tell you the truth. CL
> has several implementations, and some of them (all of them?)
> have bugs.
I think you just changed the topic. If my Lisp is buggy enough that I
cannot use "try it" as a reference, I need a new Lisp. And having ported
software to ACL and MCK and LW and Corman Lisp and CLisp and CMUCL,
where the only "bug" turned out to be a bit of non-conformity (I wish it
had been a bug!), I can't see it happening. Especially on the topic: how
should newbies learn Lisp. That won't get them into the dark corners
where CL implementations sometimes get non-compliant.
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Kenny Tilton <·······@nyc.rr.com> writes:
> Alain Picard wrote:
>
>> Kenny Tilton <·······@nyc.rr.com> writes:
>>
>>>Nah, this is Lisp. Just go to the Listener and type it in, see what
>>> happens. Read up on something only if you get stuck.
>> No. Common Lisp is not like the other "one-implementation"
>> languages, where the REPL will tell you the truth. CL
>> has several implementations, and some of them (all of them?)
>> have bugs.
>
> I think you just changed the topic. If my Lisp is buggy enough that I
> cannot use "try it" as a reference, I need a new Lisp.
No, you do not. You may try something in the REPL, _think_ you
understand what happens, and go on to make egregious errors.
I know, I've been guilty of it. :-(
> Especially on
> the topic: how should newbies learn Lisp.
Newbies to lisp, or newbies to programming? Newbies trying
to do some hobbyiest programming, or newbies hired to ship
commercial applications?
I think you may find the answer varies a fair bit with the
extra context which every "newbie" brings with him to this task...
But when all is said and done: how long does it take
to hit one keystroke in ILISP and read the Hyperspec page on
an unfamiliar form? How could this possibly _NOT_ be
a good thing to do? I'm baffled.
Alain Picard wrote:
> But when all is said and done: how long does it take
> to hit one keystroke in ILISP and read the Hyperspec page on
> an unfamiliar form? How could this possibly _NOT_ be
> a good thing to do? I'm baffled.
I use and recommend the Hyperspec daily. The context was a choice
between the REPL and taking the ANSI spec to Starbuck's for a week.
That said, I am not a good reader, and I could not understand CLTL2
until I already knew Lisp. I did not know of the h/s until I knew Lisp,
so I do not know if it would have been clearer to me as a newbie.
Finally, even the h/s can give up insight slowly, while:
"I hear and I forget, I see and I remember, I do and I understand.".
- Confucius
kenny
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey
Kenny Tilton <·······@nyc.rr.com> writes:
> Alain Picard wrote:
>
> > But when all is said and done: how long does it take
> > to hit one keystroke in ILISP and read the Hyperspec page on
> > an unfamiliar form? How could this possibly _NOT_ be
> > a good thing to do? I'm baffled.
>
> I use and recommend the Hyperspec daily. The context was a choice
> between the REPL and taking the ANSI spec to Starbuck's for a week.
I found the best approach was to browse the chapter of the spec that
you're interested in, and find some interesting symbols. Pull up a
repl, look at the arglists, read the docstrings, play with them until
you think you get how they work, then pull up the spec again, to make
sure you're right. It's a lot easier to understand the written
description, once you've played with it a bit.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Alain Picard wrote
> But when all is said and done: how long does it take to
> hit one keystroke in ILISP and read the Hyperspec page on
> an unfamiliar form? How could this possibly _NOT_ be a
> good thing to do? I'm baffled.
I quote from http://www.lispworks.com/reference/HyperSpec/Body/s_let_l.htm
>The form
>
> (let ((var1 init-form-1)
> (var2 init-form-2)
> ...
> (varm init-form-m))
> declaration1
> declaration2
> ...
> declarationp
> form1
> form2
> ...
> formn)
>
> first evaluates the expressions init-form-1, init-form-2,
> and so on, in that order, saving the resulting values. Then
> all of the variables varj are bound to the corresponding
> values; each binding is lexical unless there is a special
> declaration to the contrary. The expressions formk are then
> evaluated in order; the values of all but the last are
> discarded (that is, the body of a let is an implicit progn).
One has to be extremely sharp to spot that declaration1,
declaration2,...,declarationp do *not* exhaust the possible
hiding places for a "special declaration to the contrary."
As a community we have chosen to retain this vexingly
infelicitous wording on a key page of our documentation
from one century to the next. The damage goes beyond the
specific confusions it permits. It sends a message to the
wider programming community about the vitality and
professionalism of the CL community, and it is a message
that we ought not to be sending.
Alan Crowe
Alan Crowe wrote:
>
> Alain Picard wrote
> > But when all is said and done: how long does it take to
> > hit one keystroke in ILISP and read the Hyperspec page on
> > an unfamiliar form? How could this possibly _NOT_ be a
> > good thing to do? I'm baffled.
>
> I quote from http://www.lispworks.com/reference/HyperSpec/Body/s_let_l.htm
>
> ...
> One has to be extremely sharp to spot that declaration1,
> declaration2,...,declarationp do *not* exhaust the possible
> hiding places for a "special declaration to the contrary."
>
the page which appears for me when i follow the above link contains an anchor,
which in one click produces a page-long discussion of "special", and in a
second click produces an analogous discussion of "declare". are these things
that hard to follow?
...
>>>>> "AC" == Alan Crowe <····@cawNOtech.freeSPAMserve.co.uk> writes:
[...]
AC> I quote from
AC> http://www.lispworks.com/reference/HyperSpec/Body/s_let_l.htm
[edited the quote out]
AC> One has to be extremely sharp to spot that declaration1,
AC> declaration2,...,declarationp do *not* exhaust the possible
AC> hiding places for a "special declaration to the contrary."
FWIW, I am neither extremely sharp nor a native speaker of English
but I never assumed they would.
Upon reading that section I have no touble thinking that a special
proclamation could already exist. If that is what you think people
would miss (that is, I didn't miss anything else) then I'd say it
would be because they don't have a working knowledge of the language
as far as specials are concerned (how will you bind specials
otherwise? How will all those specials like the ones that control the
reader etc. work?) If that is the case they probably ought to also
read an intro book or read the spec very carefully. The section below
does have examples
http://www.lispworks.com/reference/HyperSpec/Body/d_specia.htm
(so yes I did check now)
Now, if what you were after was a footnote warning against confusion
I don't see much harm in that _except_ then, for consistency, one would
need to do that kind of warning elsehwere possibly leading to bloat in
the standard. I do, however, whoeartedly agree if what you are after is
something extending the Hyperspec that people could just pull up in
emacs (an improved/revised on-line CLtL2).
AC> As a community we have chosen to retain this vexingly
AC> infelicitous wording on a key page of our documentation from
AC> one century to the next. The damage goes beyond the specific
AC> confusions it permits. It sends a message to the wider
AC> programming community about the vitality and professionalism
AC> of the CL community, and it is a message that we ought not to
AC> be sending.
I think people who get bitten by this will come to the realization that
the hyperspec is written in a precise but economical manner and the
_next_ time they will take what's said literally.
cheers,
BM
Alan Crowe wrote:
> Use it when your program lives in multiple files and has
> multiple versions. For example
>
> File A has (defvar *flag* 'complex)
> File B has (defvar *flag* 'simple)
>
> You build the simple version by loading file B.
> Then you quit and start afresh.
> You build the complex version by loading file A, followed
> by file B. Although (defvar *flag* 'simple) was excuted
> last, *flag* => complex, because defvar only evaluates its
> value form if there is no prior initialisation.
>
> See the hyperspec for other cunning and devious uses of this
> cunning and devious command.
See the Human Resources for your severance check if you are using
load-file as your application init function.
--
http://tilton-technology.com
What?! You are a newbie and you haven't answered my:
http://alu.cliki.net/The%20Road%20to%20Lisp%20Survey