Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

What was the impetus for the LAMBDA macro?

151 views
Skip to first unread message

Peter Seibel

unread,
Oct 14, 2003, 11:18:02 PM10/14/03
to
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 pe...@javamonkey.com

Lisp is the red pill. -- John Fraser, comp.lang.lisp

Lars Brinkhoff

unread,
Oct 15, 2003, 1:33:55 AM10/15/03
to
Peter Seibel <pe...@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/

Alan Crowe

unread,
Oct 15, 2003, 8:44:43 AM10/15/03
to
Lars Brinkhoff wrote

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

Joe Marshall

unread,
Oct 15, 2003, 11:20:32 AM10/15/03
to

> 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 <al...@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)
)
)
)

Pascal Bourguignon

unread,
Oct 15, 2003, 12:03:35 PM10/15/03
to

Alan Crowe <al...@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.

Alan Crowe

unread,
Oct 15, 2003, 2:38:57 PM10/15/03
to
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

Pascal Bourguignon

unread,
Oct 15, 2003, 11:10:07 PM10/15/03
to
Alan Crowe <al...@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.

Alain Picard

unread,
Oct 16, 2003, 12:26:16 PM10/16/03
to
Pascal Bourguignon <sp...@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)

Alan Crowe

unread,
Oct 16, 2003, 7:25:52 AM10/16/03
to
> 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.

Tim Bradshaw

unread,
Oct 16, 2003, 10:22:36 AM10/16/03
to
* 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

Kenny Tilton

unread,
Oct 16, 2003, 11:38:11 AM10/16/03
to

Alain Picard wrote:
> Pascal Bourguignon <sp...@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

Pascal Bourguignon

unread,
Oct 16, 2003, 1:01:04 PM10/16/03
to

Tim Bradshaw <t...@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 :-(

Bulent Murtezaoglu

unread,
Oct 16, 2003, 1:47:15 PM10/16/03
to
>>>>> "AC" == Alan Crowe <al...@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

Joe Marshall

unread,
Oct 16, 2003, 2:05:29 PM10/16/03
to
Kenny Tilton <kti...@nyc.rr.com> writes:

> Alain Picard wrote:
>> Pascal Bourguignon <sp...@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

unread,
Oct 16, 2003, 2:25:37 PM10/16/03
to

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.

Kenny Tilton

unread,
Oct 16, 2003, 3:57:37 PM10/16/03
to
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.

Tim Bradshaw

unread,
Oct 16, 2003, 7:27:41 PM10/16/03
to
* 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.)

Alan Crowe

unread,
Oct 17, 2003, 5:14:25 AM10/17/03
to
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

Rmagere

unread,
Oct 17, 2003, 5:20:00 AM10/17/03
to
> 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).


Tom Evans

unread,
Oct 17, 2003, 5:57:17 AM10/17/03
to
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

Avi Blackmore

unread,
Oct 17, 2003, 6:54:09 AM10/17/03
to
Tim Bradshaw <t...@cley.com> wrote in message news:<ey3vfqp...@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

Rmagere

unread,
Oct 17, 2003, 7:35:11 AM10/17/03
to
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.


Tim Bradshaw

unread,
Oct 17, 2003, 7:50:17 AM10/17/03
to
* 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

unread,
Oct 17, 2003, 8:12:50 AM10/17/03
to
* 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

Tom Evans

unread,
Oct 17, 2003, 8:48:40 AM10/17/03
to
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.

Christian Lynbech

unread,
Oct 17, 2003, 8:47:58 AM10/17/03
to
>>>>> "Tim" == Tim Bradshaw <t...@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.
- pet...@hal.com (Michael A. Petonic)

Daniel Barlow

unread,
Oct 17, 2003, 8:58:31 AM10/17/03
to
Tim Bradshaw <t...@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

Kenny Tilton

unread,
Oct 17, 2003, 9:39:10 AM10/17/03
to

Tim Bradshaw wrote:

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

Ingvar Mattsson

unread,
Oct 17, 2003, 9:57:18 AM10/17/03
to
Kenny Tilton <kti...@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

Tim Bradshaw

unread,
Oct 17, 2003, 10:31:11 AM10/17/03
to
* 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

Gareth McCaughan

unread,
Oct 17, 2003, 3:14:25 PM10/17/03
to
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

prunes...@comcast.net

unread,
Oct 18, 2003, 1:21:31 AM10/18/03
to
Gareth McCaughan <gareth.m...@pobox.com> writes:

> Oxford spelling: Magdalen.
> Cambridge spelling: Magdalene.

Presumably the Cambridge spelling is longer because
they are `can't abridge ians'.

Gareth McCaughan

unread,
Oct 18, 2003, 4:14:08 AM10/18/03
to
prunes...@comcast.net writes:

Ouch.

Alan Crowe

unread,
Oct 18, 2003, 4:34:52 AM10/18/03
to
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

Paul F. Dietz

unread,
Oct 18, 2003, 7:09:47 AM10/18/03
to
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

james anderson

unread,
Oct 18, 2003, 7:23:35 AM10/18/03
to

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.

...

Christophe Rhodes

unread,
Oct 18, 2003, 7:49:51 AM10/18/03
to
james anderson <james.a...@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)

james anderson

unread,
Oct 18, 2003, 9:08:19 AM10/18/03
to

Christophe Rhodes wrote:
>
> james anderson <james.a...@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)))))

...

prunes...@comcast.net

unread,
Oct 18, 2003, 10:09:27 AM10/18/03
to

stUdlIfIed Code but All lowErcAsE pOstinG?


james anderson <james.a...@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.

james anderson

unread,
Oct 18, 2003, 11:58:54 AM10/18/03
to

prunes...@comcast.net wrote:
>
> stUdlIfIed Code but All lowErcAsE pOstinG?
>
> james anderson <james.a...@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.

...

Alan Crowe

unread,
Oct 18, 2003, 2:18:54 PM10/18/03
to
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

unread,
Oct 18, 2003, 2:27:48 PM10/18/03
to
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

james anderson

unread,
Oct 18, 2003, 2:41:54 PM10/18/03
to

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.

...

Tim Bradshaw

unread,
Oct 18, 2003, 4:06:50 PM10/18/03
to
* 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

Rmagere

unread,
Oct 18, 2003, 4:54:50 PM10/18/03
to
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.


prunes...@comcast.net

unread,
Oct 18, 2003, 7:13:02 PM10/18/03
to
james anderson <james.a...@setf.de> writes:

> prunes...@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.

Alain Picard

unread,
Oct 19, 2003, 8:44:10 AM10/19/03
to
Kenny Tilton <kti...@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.


Paolo Amoroso

unread,
Oct 19, 2003, 6:19:59 AM10/19/03
to
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 <amo...@mclink.it>

Thomas A. Russ

unread,
Oct 20, 2003, 1:27:50 PM10/20/03