One last chapter to review! Last chance! One-day only!
Peter Seibel
my book. All other chapters have been through copy-edit or even page
proof. The introduction has been, in many ways, the hardest chapter to
write and I may yet rewrite the whole thing again. My goal is to draw
in people who already have some interest in Lisp and, ideally, also to
be able to pique the curiosity of someone who is even a little
sceptical about Lisp. If you have a chance to look at this chapter
today or tomorrow (Saturday or Sunday), I'd be quite to know whether
you think this version will serve those purposes. (Don't bother with
punctuation and spelling errors--my copy editor is quite good at
catching that stuff and this hasn't gone to her yet. Plus, as I say,
this may be dramatically rewritten one more time.) The new version is
linked off the main page at:
<http://www.gigamonkeys.com/book/>
in HTML and PDF and "source" as:
<http://www.gigamonkeys.com/book/introduction-why-lisp.html>
<http://www.gigamonkeys.com/book/introduction-why-lisp.pdf>
<http://www.gigamonkeys.com/book/introduction-why-lisp.txt>
For comparison, you can also see the old intro at:
<http://www.gigamonkeys.com/book/intro-1st-draft.html>
<http://www.gigamonkeys.com/book/intro-1st-draft.pdf>
As a final bit of context, here's the text of a letter to the reader
that will appear on the back cover of the book.
Dear Reader,
"Practical Common Lisp" ... isn't that an oxymoron? If you're like
most programmers, you probably know something about Lisp--from a
comp sci course in college or from learning enough Elisp to
customize Emacs a bit. Or maybe you just know someone who won't shut
up about Lisp, the greatest language ever. But you probably never
figured you'd see "practical" and "Lisp" in the same book title.
Yet, you're reading this; you must want to know more. Maybe you
believe learning Lisp will make you a better programmer in any
language. Or maybe you just want to know what those Lisp fanatics
are yammering about all the time. Or maybe you have learned some
Lisp but haven't quite made the leap to using it to write
interesting software.
If any of those is true, this book is for you. Using Common Lisp, an
ANSI standardized, industrial-strength dialect of Lisp, I show you
how to write software that goes well beyond silly academic exercises
or trivial editor customizations. And I show you how Lisp--even with
many of its features adopted by other languages--still has a few
tricks up its sleeve.
But unlike many Lisp books, this one doesn't just touch on a few of
Lisp's greatest features and then leave you on your own to actually
use them. I cover all the language features you'll need to write
real programs and devote well over a third of the book to developing
non-trivial software--a statistical spam filter; a library for
parsing binary files; and a server for streaming MP3s over a network
complete with an online MP3 database and web interface.
So turn the book over, open it up, and see for yourself how
eminently practical using the greatest language ever invented can
be.
Sincerely,
Peter Seibel
Thanks.
-Peter
--
Peter Seibel pe...@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
William Bland
> I just put up a substantially revised 2nd draft of the introduction to
> my book.
I like it very much. The only thing I would add is a footnote to explain
what a language lawyer is. I know, but I'm planning to give the book to
people who probably wouldn't.
Cheers,
Bill.
Kent M Pitman
For anyone who uses this term, it's worth occasionally also making note of
the fact that the term "lawyer" is often abused in this context, even though
I've more or less acquiesced to the idea that the term will be used this way,
in part because I have no better name to suggest.
A lawyer, in the US legal system, is typically a partisan advocate for one side
or the other who argues a position on the part of a usually-paying party.
There are usually two of these, and "justice" (such as it is) is achieved by
them duking it out before a judge or jury or both, who finally say which
argument they believe.
SOMETIMES in the US, a lawyer is someone you just go to for advice
about whether you can get away with something without it leading to
you being charged with being a bad guy, and I suppose in that sense
some of us that are called "language lawyers" are giving similar
advice, but it's rare in the legal profession that a lawyer would
offer such information publicly, since the mere "calling attention to"
of your issue is usually a problem there.
ANSI has a way of doing the heavyweight equivalent of adjudicating
disputes, but usually when the term "language lawyer" is being used, the
people thus called are being a bit less partisan and a bit more interested
in consensus building. (I'm told some other countries do their lawyering
this way, but I have no idea how well it really works.)
The formal giving of "official advisory rulings" about compliance and
interpretation is something ANSI and other organizations specifically
forbids us as individuals from doing in their name, and recommends we
avoid doing in general.
Sometimes I think it's a bit more like Jewish Rabbis communicating in and
about the Talmud... something more of a scholarly venue/endeavor/occupation.
Probably, in the end, finding a correct term or even explaining why
this is different than the ordinary use of lawyer is not worth the
effort. Maybe the term is close enough. But it still draws my
attention from time to time, and I just wanted to at least log my
thoughts on this since it comes up from time to time.
Alain Picard
> William Bland <new...@abstractnonsense.com> writes:
>
>> On Sun, 20 Feb 2005 00:57:14 +0000, Peter Seibel wrote:
>>
>> > I just put up a substantially revised 2nd draft of the introduction to
>> > my book.
>>
>> I like it very much. The only thing I would add is a footnote to explain
>> what a language lawyer is. I know, but I'm planning to give the book to
>> people who probably wouldn't.
>
> For anyone who uses this term, it's worth occasionally also making note of
> the fact that the term "lawyer" is often abused in this context, even though
> I've more or less acquiesced to the idea that the term will be used this way,
> in part because I have no better name to suggest.
>
Perhaps just a reference to
http://www.jargon.net/jargonfile/l/languagelawyer.html
would suffice.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <1995May29....@netlabs.com>
Trent Buck
> Dear Reader,
>
> "Practical Common Lisp" ... isn't that an oxymoron? If you're like
> most programmers, you probably know something about Lisp--from a
> comp sci course in college or from learning enough Elisp to
> customize Emacs a bit. Or maybe you just know someone who won't shut
> up about Lisp, the greatest language ever. But you probably never
> figured you'd see "practical" and "Lisp" in the same book title.
>
> Yet, you're reading this; you must want to know more. Maybe you
> believe learning Lisp will make you a better programmer in any
> language. Or maybe you just want to know what those Lisp fanatics
> are yammering about all the time. Or maybe you have learned some
> Lisp but haven't quite made the leap to using it to write
> interesting software.
>
> If any of those is true, this book is for you. Using Common Lisp, an
> ANSI standardized, industrial-strength dialect of Lisp, I show you
s/I show you/I will show you/
> how to write software that goes well beyond silly academic exercises
> or trivial editor customizations. And I show you how Lisp--even with
> many of its features adopted by other languages--still has a few
> tricks up its sleeve.
>
> But unlike many Lisp books, this one doesn't just touch on a few of
> Lisp's greatest features and then leave you on your own to actually
> use them. I cover all the language features you'll need to write
Past tense and passive voice might be better -- "All the language
features ... are covered."
> real programs and devote well over a third of the book to developing
> non-trivial software--a statistical spam filter; a library for
> parsing binary files; and a server for streaming MP3s over a network
> complete with an online MP3 database and web interface.
>
> So turn the book over, open it up, and see for yourself how
> eminently practical using the greatest language ever invented can
> be.
Good stuff! As you know, the blurb is the most important part :-)
--
-trent
<foo> Even a plain girl can get laid whenever she wants.
<foo> Just go up to a guy: "sex?"
<foo> A guy can't do such things.
<bar> Maybe you haven't gone up to the right guy?
Trent Buck
> A lawyer, in the US legal system, is typically a partisan advocate for one side
> or the other who argues a position on the part of a usually-paying party.
> There are usually two of these, and "justice" (such as it is) is achieved by
> them duking it out before a judge or jury or both, who finally say which
> argument they believe.
That's a funny way to spell "lie" :-)
--
Trent "Everything I know about the US justice system I learned from
television" Buck
Ron Garret
Kent M Pitman <pit...@nhplace.com> wrote:
> Sometimes I think it's a bit more like Jewish Rabbis communicating in and
> about the Talmud... something more of a scholarly venue/endeavor/occupation.
Yeah, but "language lawyer" alliterates so much better than "language
rabbi."
;-)
rg
Harald Hanche-Olsen
Or "language ayatollah"?
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Debating gives most of us much more psychological satisfaction
than thinking does: but it deprives us of whatever chance there is
of getting closer to the truth. -- C.P. Snow
Tayssir John Gabbour
> sceptical about Lisp. If you have a chance to look at this chapter
> today or tomorrow (Saturday or Sunday), I'd be quite to know whether
> you think this version will serve those purposes.
> <http://www.gigamonkeys.com/book/introduction-why-lisp.pdf>
> <http://www.gigamonkeys.com/book/introduction-why-lisp.txt>
It has more of a sense of honesty than the previous intro. Not that the
previous one was dishonest; just that this new one is more personal,
and not so much marketing.
The only thing which leapt out at me was:
$ diff introduction-why-lisp.txt
introduction-why-lisp-PERSONAL-COPY.txt
477,478c477,478
< original implementation of CLOS, Common Lisp's powerful object system
< was first implemented in portable pre-CLOS Common Lisp code. This
---
> original implementation of CLOS, Common Lisp's powerful object
system,
> was first implemented in portable Common Lisp code. This
I removed the redundant-seeming word "pre-CLOS", because my eyes glazed
over a little. Acronym density. (I also added a comma, which you likely
don't care about.)
The Cold War helping lisp is one of those humorously disturbing things.
War has always been part of Lisp's landscape -- I occasionally hear a
"Lisp success story" being some logistical system's use in the Gulf
War.
(For those who believe our military stance won the cold war, get ready
for a huge debunking by the person credited as our "architect of the
Cold War," in his NYT article "The GOP Won the Cold War? Ridiculous.")
http://www.pentaside.org/article/kennan-nyt-gop-won-coldwar.html
MfG,
Tayssir
Tayssir John Gabbour
> Peter Seibel wrote:
> > sceptical about Lisp. If you have a chance to look at this chapter
> > today or tomorrow (Saturday or Sunday), I'd be quite to know
whether
> > you think this version will serve those purposes.
> > <http://www.gigamonkeys.com/book/introduction-why-lisp.html>
> > <http://www.gigamonkeys.com/book/introduction-why-lisp.pdf>
> > <http://www.gigamonkeys.com/book/introduction-why-lisp.txt>
>
Incidentally, if through some stroke of fortune you're bringing copies
of the book to the Amsterdam shindig, and your book hasn't reached
Europe yet, feel free to sign me up for a copy.
I recall David Mertz sold his freebie copies of his Python book on
Amazon's marketplace, since he was able to earn more on those copies.
And when of course it succeeds to the point where JK Rowling and
Stephen King do stints copyediting future versions, and rap artists
make frequent references to its passages like some lyrical Torah, a
little book-signing might add some nice value to those copies...
MfG,
Tayssir
Tobias C. Rittweiler
Peter Seibel wrote:
> I just put up a substantially revised 2nd draft of the
> introduction to my book. All other chapters have been through
> copy-edit or even page proof. The introduction has been, in many
> ways, the hardest chapter to write and I may yet rewrite the whole
> thing again.
I like it. And I'm looking forward seeing the dead tree version
in my mailbox.
> <http://www.gigamonkeys.com/book/introduction-why-lisp.txt>
Section `Why Lisp?', lines 395-398:
The nearest thing Common Lisp has to a motto is the koan-like
description, "the programmable programming language." While cryptic,
that description gets at the root of the advantage Common Lisp still
has over other languages.
I think this could be misread to mean "the only advantage of CL over
the other languages is macros". So I suggest to add some adjective
to `advantage', for instance "gets at the root of the most obvious
advantage" or "gets at the root of the unique advantage".
Andreas Thiele
I don't know if the referrence to AspectL is such a good idea (sorry
Pascal). I must admit, I don't know what aspect oriented programming (AOP)
is all about. What I picked up from some fellow lispers is roughly the
following:
"AOP was invented by Kiczales to bring part of the MOP to Java, as he said,
in a way the average programmer can comprehend."
If this is true, AspectL tries to introduce something into Lisp which
already is contained more advanced - the MOP.
Looking forward to the groups corrections of this statement :)
Andreas
Thomas Gagne
explore languages such mainstream languages as C, C++, and Python, and less
well known ones as Smalltalk, Eiffel, and Beta."
s/languages such mainstream languages/such mainstream languages/
jayessay
> or trivial editor customizations. And I show you how Lisp--even with
> many of its features adopted by other languages--still has a few
^--piecemeal ^--'modern'
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Peter Seibel
> Tayssir John Gabbour wrote:
>> Peter Seibel wrote:
>> > sceptical about Lisp. If you have a chance to look at this chapter
>> > today or tomorrow (Saturday or Sunday), I'd be quite to know
> whether
>> > you think this version will serve those purposes.
>> > <http://www.gigamonkeys.com/book/introduction-why-lisp.html>
>> > <http://www.gigamonkeys.com/book/introduction-why-lisp.pdf>
>> > <http://www.gigamonkeys.com/book/introduction-why-lisp.txt>
>>
>> The only thing which leapt out at me was:
>
> Incidentally, if through some stroke of fortune you're bringing
> copies of the book to the Amsterdam shindig, and your book hasn't
> reached Europe yet, feel free to sign me up for a copy.
Right on. I'm looking into getting some copies shipped to Amsterdam
for folks who want to buy one there. (Gotta figure out shipping costs,
customs, etc.)
> I recall David Mertz sold his freebie copies of his Python book on
> Amazon's marketplace, since he was able to earn more on those copies.
>
> And when of course it succeeds to the point where JK Rowling and
> Stephen King do stints copyediting future versions, and rap artists
> make frequent references to its passages like some lyrical Torah, a
> little book-signing might add some nice value to those copies...
I'll bring my Sharpie!
Barry Margolin
"Tayssir John Gabbour" <tayss...@yahoo.com> wrote:
> The Cold War helping lisp is one of those humorously disturbing things.
> War has always been part of Lisp's landscape -- I occasionally hear a
> "Lisp success story" being some logistical system's use in the Gulf
> War.
Not only Lisp owes a debt to the Cold War. Much of the space program,
and all the technologies that were spun off it, were due to wanting to
beat the Russians to the moon.
And real wars led to many other technological advances: rockets, RADAR,
SONAR, and computers. For sure these would have come about eventually,
but wars increased the urgency to develop them and provided an enormous
influx of capital to the developers.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Barry Margolin
> Sometimes I think it's a bit more like Jewish Rabbis communicating in and
> about the Talmud... something more of a scholarly venue/endeavor/occupation.
Language lawyering can perhaps be seen as a metaphor for what appears in
legal journals. It's not the actual practice of the law, but the
discussion what the law means. The equivalent of language lawyers in
the legal industry are usually referred to as "legal scholars" -- "law
lawyers" sounds redundant. Conversely, the equivalent of lawyers in the
CS industry would be programmers. Language lawyers could be called
"programming scholars".
I'm a little unsure, however, that the role Peter actually played at his
Perl and Java shops was really that of "language lawyer". Language
lawyering typically refers to the kinds of pedantic discussions that
take place in newsgroups -- is some particular construct strictly
specified by the language standard, is some implementation's behavior
conforming, etc. It seems strange that someone would actually perform
this duty in a practical programming shop.
Peter, are you sure you didn't mean to say that you were the "Perl guru"
and "Java guru" at the web shop and WebLogic, respectively?
Ulrich Hobelmann
at the beginning, but who knows where they hide?
Peter Seibel
Going by this definition from the Jargon File:
language lawyer, n. A person, usually an experienced or senior
software engineer, who is intimately familiar with many or most of
the numerous restrictions and features (both useful and esoteric)
applicable to one or more computer programming languages.
I think I was a language lawyer. But I don't see a big distinction
between this definiton and what I would understand someone to mean by
"Perl guru" except with the possible nuance that a "language lawyer"
is more likely to bend your ear with spec citations when you ask a
question than a guru, who will probably just show you how to do
something or recite an inscrutable koan.
But the point is sort of moot because I'm taking out the mention of
"language lawyer" for other reasons.
Rahul Jain
> What I picked up from some fellow lispers is roughly the following:
>
> "AOP was invented by Kiczales to bring part of the MOP to Java, as he said,
> in a way the average programmer can comprehend."
AspectJ really only adds :before, and :after, and :around to Java, along
with some small conditionalization of those methods, AFAICT.
> If this is true, AspectL tries to introduce something into Lisp which
> already is contained more advanced - the MOP.
AspectL brings aspect-oriented programming to CL. That is, it allows the
interactions among objects depend on the path from which the interaction
was invoked (the "aspect" of the code execution at that point).
--
Rahul Jain
rj...@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
David Steuber
> You might want to search your text for "the the". I've only noticed
> one at the beginning, but who knows where they hide?
Usually between Paris and Spring.
I don't have anything specific to offer. But the introduction didn't
really grab me. I have no idea why. I did have the thought that
something like The Story of Mac would be cool. Some sort of prequel
perhaps.
The road to lisp story was nice. Peter, what if you cast yourself in
the role of Mac before he learned lisp and go from there in a rtl sort
of story?
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
Peter Seibel
> Ulrich Hobelmann <u.hob...@web.de> writes:
>
>> You might want to search your text for "the the". I've only noticed
>> one at the beginning, but who knows where they hide?
>
> Usually between Paris and Spring.
>
> I don't have anything specific to offer. But the introduction didn't
> really grab me. I have no idea why. I did have the thought that
> something like The Story of Mac would be cool. Some sort of prequel
> perhaps.
>
> The road to lisp story was nice. Peter, what if you cast yourself in
> the role of Mac before he learned lisp and go from there in a rtl sort
> of story?
Sorry, the one-day only offer has expired. I turned in my 3rd draft to
the copy editor last night. But that's probably okay since I'm not
sure I'd have had the energy to attempt what you're suggesting. That
approach will have to wait for the next fool crazy enough to write a
Lisp book. ;-)
Damien Kick
> In article <uekfbj...@nhplace.com>,
> Kent M Pitman <pit...@nhplace.com> wrote:
>
> > Sometimes I think it's a bit more like Jewish Rabbis communicating
> > in and about the Talmud [...]
>
> Yeah, but "language lawyer" alliterates so much better than "language
> rabbi."
Maybe there is an alliterative Hebrew phrase for this <smile>.
Damien Kick
> I just put up a substantially revised 2nd draft of the introduction
> to my book. [...] If you have a chance to look at this chapter
> today or tomorrow (Saturday or Sunday), I'd be quite to know whether
> you think this version will serve those purposes.
I liked it. I like the anecdote about your father's [1] exposure to
Lisp but I wonder if it might be a good idea to explicitly dispel FUD
more aggressively within the first few pages of the introduction.
Your father's experience hightlights the practical aspect very well,
i.e. it helped deliver on-time and on-budget, and you do attack the
recursive, interpreted bugaboo in the text, you mention how AI
required not only power but also performance, but I wonder if maybe
these things shouldn't be emphasized more, somehow. Maybe it should
even be a subtitle: _Practical Common Lisp: Doesn't have to be
interpreted, not necessarily recursive_ <laugh>. I realize, though,
that there is a balance to be struck with this, e.g. one wouldn't want
the tone to be overly defensive, for example. <pause> I suppose it
could go either way and I'm not sure I've a real strong feeling one
way or the other. I'm probably just niggling but this would be the
only nit at which I'm picking in my head (which is far better than
picking nits from off of one's head) after reading this revision.
<laugh> I lied. One other niggle: "... the koan-like description,
'the programmable programming language.'" That phrase doesn't really
strike me as very koan-like. What is the sound of one hand clapping?
Does a dog have buddha nature? These phrases/questions are far more
paradoxical, immune to "rational" answers, than something like "a tool
used to build tools". Programmable programming is really more of a
meta-circular kind of phrase, not nearly so esoteric or impenetrable.
<pause> Well, unless you hand it to Hofstadter [2], but this is
Practical Common Lisp, after all. There'll be no quines in your book,
AFAICT.
[1] I wonder if there's a tagline in there somehow. "Common Lisp: not
my father's Lisp." Like those car commercials that try to shake a
stodgy image. Same qualtiy brand name, new sexp <groan> image. Or is
it the same sexp image? In a certain sense, it's a lie because there
is a lot of the original Lisp in Common Lisp, AFAIK. But sound bites
lie all the time, right <smile>? <shrug> I dunno. I'm just free
associating...
[2] Does self-reference have koan nature? Hofstadter says, "It does
not."
Peter Seibel
Well, you may be right. But FWIW I probably had this AI Koan in the
back of my mind:
Moon instructs a student
One day a student came to Moon and said: "I understand how to make a
better garbage collector. We must keep a reference count of the
pointers to each cons."
Moon patiently told the student the following story:
"One day a student came to Moon and said: 'I understand how to
make a better garbage collector...
Pascal Bourguignon
> <laugh> I lied. One other niggle: "... the koan-like description,
> 'the programmable programming language.'" That phrase doesn't really
> strike me as very koan-like. What is the sound of one hand clapping?
> Does a dog have buddha nature? These phrases/questions are far more
> paradoxical, immune to "rational" answers, than something like "a tool
> used to build tools". Programmable programming is really more of a
> meta-circular kind of phrase, not nearly so esoteric or impenetrable.
> <pause> Well, unless you hand it to Hofstadter [2], but this is
> Practical Common Lisp, after all. There'll be no quines in your book,
> AFAICT.
It seems to me you missed the meaning of "The Programmable Programming
Language."
Imagine for example, a programming language where you can add
(ie. program) a new ternary logical type and a new conditional
construct:
(defconstant maybe 'maybe)
(deftype toolean () '(member nil maybe t))
then you can write:
(tif (some-toolean-expression)
(print :definitely)
(print :i-dont-know)
(print :absolutely-not))
There, you would have a programmable programming language.
Thanks to macros, in lisp you have it.
(defmacro tif (condition &optional iftrue ifmaybe iffalse)
`(let ((c ,condition)) ;; exercise for the reader: insert gensyms
(cond
((not (or (null c) (eq c maybe))) ,iftrue)
((eq c maybe) ,ifmaybe)
(t ,iffalse))))
In (most) other languages, you cannot add special operators, you can
only add functions, and when you don't have lambdas or "blocs", you
can't reach this same level where you've _modified_ the programming
language you're using.
In conclusion, lisp (thanks to it's macros) is The Programmable
Programming Language.
(And Smalltalk, thanks to it's object purity and blocs can be too a
programmable programing language).
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
Coby Beck
"Rahul Jain" <rj...@nyct.net> wrote in message
news:87psyua...@nyct.net...
> "Andreas Thiele" <nospa...@nospam.com> writes:
>
>> What I picked up from some fellow lispers is roughly the following:
>>
>> "AOP was invented by Kiczales to bring part of the MOP to Java, as he
>> said,
>> in a way the average programmer can comprehend."
>
> AspectJ really only adds :before, and :after, and :around to Java, along
> with some small conditionalization of those methods, AFAICT.
I recently attended a talk by Kiczales in Vancouver and finally got a bit
better grasp of AspectJ and this is not quite the whole story. I found him
to be interesting and charismatic.
The most succinct description I can come up with is that it is like :before,
and :after, and :around methods but with an extended concept of a generic
function or maybe just divorced from that concept. That is to say that
these extra methods (called point cuts) can be run in conjunction with any
other method you declare. So its like defining a :before method on foo and
bar at the same time, the same code will run whenever foo or bar run. Plus
these point cuts are nestable inside each other.
This seemed to be the fundamental concept but I believe the strongest
selling point for AspectJ was the IDE he demo'ed and the integration of
tools based on Point Cuts and Aspects.
Anyway, I spoke to him after and acknowledged that :before, and :after, and
:around methods are not enough to do what Aspects do. I did suggest that
some macrology might be enough but he dismissed it with an objection that
didn't make sense to me and did not have time to take my suggested approach
seriously. Then again, he did invite me to try for myself and exchange
email but I have not had the time.
I will say it was obvious from his reactions to mentions of Lisp that
leaving it behind is not a purely technical decision.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
lin8080
Peter Seibel schrieb:
...
> As a final bit of context, here's the text of a letter to the reader
> that will appear on the back cover of the book.
>
> Dear Reader,
...
Hi
I missed the word "newbie".
else:
(Many people see/read ...lisp... and in their heads the aha-this-box
sort it away)
So, please adress this text (on the backside of your book) to "not yet
lisp-users" a bit more.
stefan
Andreas Thiele
"lin8080" <lin...@freenet.de> schrieb im Newsbeitrag
news:421C5DDB...@freenet.de...
...
> Peter Seibel schrieb:
...
For 18 month I did nothing else than Lisp programming. Still I feel a bit to
be a newbie and find Peters book very helpful. Most probably because I
didn't write a Lisp myself? Or perhaps because thus some easy questions
still make me nervous :)
{what's wrong with: (funcall #'(setf car) 3 '(1 2 3))}
If you insist on the "newbie" term, it should be made clear, people will be
newbies for quite a long time. I think the word 'practical' within the title
is sufficient.
Andreas
Peter Lewerin
> I just put up a substantially revised 2nd draft of the introduction to
I just got a splendid idea. Since the name "Lisp" carries a lot of
negative connotations for most non-lispers, why not change the name of
the language to attract more readers?
I suggest you rename the book "Practical Common Proccs" (Proccs =
Processor of Cons Structures) and replace all occurrences of "Lisp" in
the text with "Proccs(tm)".
I realize it's a bit late in the day, but hopefully it won't be
impossible to revise the whole text in this way. I'm sure the
publisher will agree that the extra effort will pay off in the long
run.
Good luck!
PS: If you don't like "Proccs", there are of course other
possibilities for acronymized names, such as "FUnctions on Cons
Cells". The main thing would be that the name has a nice and
dignified ring to it.
Pascal Bourguignon
> PS: If you don't like "Proccs", there are of course other
> possibilities for acronymized names, such as "FUnctions on Cons
> Cells". The main thing would be that the name has a nice and
> dignified ring to it.
L++
And if you add some .NET features to CL, you could call it: L#
"Look Mom! I'm programming in L++!". Sounds good.
Kalle Olavi Niemitalo
> Conversely, the equivalent of lawyers in the CS industry would
> be programmers. Language lawyers could be called "programming
> scholars".
To me, a "programming scholar" sounds like someone knowledgeable
of programming in general: one who examines multiple programming
languages and methodologies, compares their features objectively,
and attempts to either advance the state of the art or at least
attract fellow programmers towards it. In her spare time, such
a person might design obscure continuation-based programming
languages or implement Turing machines in Sendmail.
In contrast, I would only expect a "language lawyer" to know the
current specification of one language thoroughly. The language
lawyer seeks out unexplored consequences of the specification and
then marks his territory by publishing his findings. He likes to
dream up hypothetical implementations that do everything in the
most perverse manner allowed by the specification.
Of course, the same person can be both.
David Sletten
Except when she is not a he... :)
Karl A. Krueger
> In contrast, I would only expect a "language lawyer" to know the
> current specification of one language thoroughly. The language
> lawyer seeks out unexplored consequences of the specification and
> then marks his territory by publishing his findings. He likes to
> dream up hypothetical implementations that do everything in the
> most perverse manner allowed by the specification.
... like the Scheme systems that evaluate function parameters in
random order?
--
Karl A. Krueger <kkru...@example.edu> { s/example/whoi/ }
If lots of people are doing something, and it isn't working for them,
don't expect that you're special and that it will work for you.
David Steuber
> PS: If you don't like "Proccs", there are of course other
> possibilities for acronymized names, such as "FUnctions on Cons
> Cells". The main thing would be that the name has a nice and
> dignified ring to it.
I needed to clean my monitor anyway.
lin8080
Pascal Bourguignon schrieb:
> peter....@swipnet.se (Peter Lewerin) writes:
> > PS: If you don't like "Proccs", there are of course other
> > possibilities for acronymized names, such as "FUnctions on Cons
> > Cells". The main thing would be that the name has a nice and
> > dignified ring to it.
> L++
L-Grid ()
stefan :)
lin8080
Andreas Thiele schrieb:
> "lin8080" <lin...@freenet.de> schrieb im Newsbeitrag
> > Hi
> > I missed the word "newbie".
> If you insist on the "newbie" term, it should be made clear, people will be
> newbies for quite a long time. I think the word 'practical' within the title
> is sufficient.
Well ok. No newbie, no beginners or eq.
The Lisp world is so large, it seems impossible to me to press all stuff
into on book. For myself this light shines through a small
(timed)window, but it is enough to work with. And what I saw from this
book, practical lisp is the right description.
steafn
PS: is it time conform to add PL2 hm?
Matt Curtin
>> The language lawyer seeks out unexplored consequences of the
>> specification and then marks his territory by publishing his
>> findings. He likes to dream up hypothetical implementations that
>> do everything in the most perverse manner allowed by the
>> specification.
>
> Except when she is not a he... :)
\begin[english]{languagelawyer}
Even a female language lawyer is covered by the aforementioned
description since English grammar requires the pronoun "he" when
the sex of the antecedent is unknown.
\end{languagelawyer}
(I think I'll refrain from crossposting to alt.english.usage, where
language lawyers have debated this ad nauseum.)
--
Matt Curtin, author of Brute Force: Cracking the Data Encryption Standard
Founder of Interhack Corporation +1 614 545 4225 http://web.interhack.com/
Forensic Computing | Information Assurance | Managed Information Technology
William Bland
> David Sletten <da...@slytobias.com> writes:
>
>>> The language lawyer seeks out unexplored consequences of the
>>> specification and then marks his territory by publishing his
>>> findings. He likes to dream up hypothetical implementations that
>>> do everything in the most perverse manner allowed by the
>>> specification.
>>
>> Except when she is not a he... :)
>
> \begin[english]{languagelawyer}
> Even a female language lawyer is covered by the aforementioned
> description since English grammar requires the pronoun "he" when
> the sex of the antecedent is unknown.
> \end{languagelawyer}
I think the point was that the pronoun got *switched* halfway through the
post (from female to male), and so there seems no possibility for the
statement "Of course, the same person can be both." to be true.
Cheers,
Bill.
Joerg Hoehle
> {what's wrong with: (funcall #'(setf car) 3 '(1 2 3))}
CLHS § 5.1.1.2 Setf Expansions
For each standardized accessor function F, unless it is explicitly
documented otherwise, it is implementation-dependent whether the
ability to use an F form as a setf place is implemented by a setf
expander or a setf function. Also, it follows from this that it is
implementation-dependent whether the name (setf F) is fbound.
I.e. (setf (car x) y) is not equivalent to (funcall #'(setf car) ...)
because #'(setf car) is not portable (conforming?) CL.
BTW, Cormanlisp 2.01 wants the opposite argument order:
(funcall #'(setf car) (list 1 2 3) 'a)
I'm unsure whether this is a bug in CCL or whether people can just not
expect anything from #'(SETF CAR) in implementations where it is defined.
BTW2, an attempt of destructively modifying the quoted and thus
constant form '(1 2 3) is an error anyway. Use LIST when you need this.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
Bob Woodham
good idea if one wants to support parallelism. That is, one can distribute
argument evaluation to different processes/processors in parallel without
worrying about the order in which the actual evaluations will complete.
This is true of Scheme. By the way, it's also true of C/C++.
What strikes as perverse is to write code that depends upon the order of
argument evaluation.
rydis
> On 2005-02-25, Karl A. Krueger <kkru...@example.edu> wrote:
> > Kalle Olavi Niemitalo <k...@iki.fi> wrote:
> >> In contrast, I would only expect a "language lawyer" to know the
> >> current specification of one language thoroughly. The language
> >> lawyer seeks out unexplored consequences of the specification and
> >> then marks his territory by publishing his findings. He likes to
> >> dream up hypothetical implementations that do everything in the
> >> most perverse manner allowed by the specification.
> > ... like the Scheme systems that evaluate function parameters in
> > random order?
> Leaving the order of evaluation of arguments to a function
> unspecified is a good idea if one wants to support parallelism.
> That is, one can distribute argument evaluation to different
> processes/processors in parallel without worrying about the order in
> which the actual evaluations will complete.
> This is true of Scheme. By the way, it's also true of C/C++.
There are good reasons to have an unspecified argument evaluation
order. (Besides parallellism, it might also be useful for optimization
reasons.)
There are very few good reasons to have an implementation actively
randomize the evaluation order, just as there are few good reasons
to randomly be perverse whenever the spec says "unspecified" in
other situations, unless you are developing an implementation that
has as its purpose to be a spec-compliance-tester for code.
> What strikes as perverse is to write code that depends upon the
> order of argument evaluation.
Not when that order is specified (in the language or the
implementation). Why would it be?
'mr
--
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_
Marcin 'Qrczak' Kowalczyk
> Leaving the order of evaluation of arguments to a function unspecified is a
> good idea if one wants to support parallelism. That is, one can distribute
> argument evaluation to different processes/processors in parallel without
> worrying about the order in which the actual evaluations will complete.
>
> This is true of Scheme. By the way, it's also true of C/C++.
No, it's false for both. They require the result to be consistent with
some sequential ordering.
--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
David Steuber
> > What strikes as perverse is to write code that depends upon the
> > order of argument evaluation.
>
> Not when that order is specified (in the language or the
> implementation). Why would it be?
I was sort of wondering the same thing. Isn't something like:
(if (foo) (bar) (baz))
rather dependent on the order of evaluation?
Although I can see where you might be standing on shaky ground if you
are doing foo bar baz for side effects in something like:
(and (foo) (bar) (baz))
But even that can be perfectly fine.
Trent Buck
> > > What strikes as perverse is to write code that depends upon the
> > > order of argument evaluation.
> >
> > Not when that order is specified (in the language or the
> > implementation). Why would it be?
>
> I was sort of wondering the same thing. Isn't something like:
>
> (if (foo) (bar) (baz))
Of course, IF and AND aren't functions.
--
Trent Buck, Student Errant
Of course the staff can tell their heads from their arses. Their heads
are the bits that are stuck up their arses. Ergo their arses must be
the bits that have heads stuck up them. -- Matthew Malthouse
Bob Woodham
wrote:
> There are good reasons to have an unspecified argument evaluation
> order. (Besides parallellism, it might also be useful for optimization
> reasons.)
Yes, Good point!
> There are very few good reasons to have an implementation actively
> randomize the evaluation order, just as there are few good reasons
> to randomly be perverse whenever the spec says "unspecified" in
> other situations, unless you are developing an implementation that
> has as its purpose to be a spec-compliance-tester for code.
Agreed. There are few reasons for randomization for the sake of
randomization. However, what may appear to be meaningless randomization may
be the consequence of some activity that is meaningful (like compiler
optimization, as you point out). In an ideal world, this might also extend to
dynamic (run-time) optimization.
I once befuddled a class by pointing out that, with gcc, the (perverse but
simple) C expression
n = n++;
produced a different final assignment to the value of n depending on the level
of optimization chosen. (ASIDE: Yes, I'm aware of the concept of "sequence
points" in C/C++ and that, accordingly, the semantics of the above expression
is indeed unspecified). Students were somewhat OK with the notion that the
result was unspecified. They were definitely not OK with the notion that the
result changed as a function of level of optimization chosen. To my chagrin,
they concluded gcc was a faulty compiler. Sigh, I never repeated that example
again (to an introductory class).
Bob Woodham
> Bob Woodham <woo...@cs.ubc.ca> writes:
>
>> Leaving the order of evaluation of arguments to a function unspecified is a
>> good idea if one wants to support parallelism. That is, one can distribute
>> argument evaluation to different processes/processors in parallel without
>> worrying about the order in which the actual evaluations will complete.
>>
>> This is true of Scheme. By the way, it's also true of C/C++.
>
> No, it's false for both. They require the result to be consistent with
> some sequential ordering.
Please elaborate.
I've not come across any "consistent with some sequential ordering"
requirement in either Scheme or C/C++ (although I'll freely admit I'm
not a programming languages person).
P.S. Thanks for raising the issue of a parallel evaluation result that
might not be consistent with any sequential ordering.
Thomas A. Russ
> There are good reasons to have an unspecified argument evaluation
> order. (Besides parallellism, it might also be useful for optimization
> reasons.)
>
> There are very few good reasons to have an implementation actively
> randomize the evaluation order,
Actually, given the first paragraph, there is perhaps good justification
for the second. Randomizing the order of evaluation will actively train
the PROGRAMMERS not to rely on the order of evaluation. With a
deterministic order of evaluation (specified or not), you will find that
that determinism is taken advantage of. If such determinism isn't
mandated by the language standard, then you run the risk of getting bugs
when (a) moving to another implementation or (b) upgrading your current
implementation.
The randomization of evaluation order at least makes the bugs appear
sooner, so they can be eliminated.
--
Thomas A. Russ, USC/Information Sciences Institute
Marcin 'Qrczak' Kowalczyk
>> No, it's false for both. They require the result to be consistent with
>> some sequential ordering.
>
> Please elaborate.
>
> I've not come across any "consistent with some sequential ordering"
> requirement in either Scheme or C/C++ (although I'll freely admit I'm
> not a programming languages person).
They say that arguments may be evaluated in any order. This doesn't
allow evaluation being interleaved or parallel.
I couldn't find this spelled explicitly in C or C++, it just follows
from the fact that there is some unspecified order between evaluation
of function arguments. In Scheme (R5RS) it is written explicitly:
4.1.3. Procedure calls
[...]
Note: Although the order of evaluation is otherwise unspecified,
the effect of any concurrent evaluation of the operator and operand
expressions is constrained to be consistent with some sequential order
of evaluation. The order of evaluation may be chosen differently for
each procecure call.
Marcin 'Qrczak' Kowalczyk
> The randomization of evaluation order at least makes the bugs appear
> sooner, so they can be eliminated.
But they would be non-deterministic. It's much harder to fix
a non-deterministic bug which manifests only sometimes and in
various ways.
David Steuber
> Spake David Steuber:
> > > > What strikes as perverse is to write code that depends upon the
> > > > order of argument evaluation.
> > >
> > > Not when that order is specified (in the language or the
> > > implementation). Why would it be?
> >
> > I was sort of wondering the same thing. Isn't something like:
> >
> > (if (foo) (bar) (baz))
> > (and (foo) (bar) (baz))
>
> Of course, IF and AND aren't functions.
True. A better example would have been:
(foo (frob-x)
(frob-y)
(something-with-x-and-y))
Not that I endorse that style of programming.
Joe Marshall
> t...@sevak.isi.edu (Thomas A. Russ) writes:
>
>> The randomization of evaluation order at least makes the bugs appear
>> sooner, so they can be eliminated.
>
> But they would be non-deterministic. It's much harder to fix
> a non-deterministic bug which manifests only sometimes and in
> various ways.
But harder still to fix a bug that never manifests.
To give an example, the standard version of MK-DEFSYSTEM uses a stable
topological sort to determine the load order. If two files are not
dependent upon each other, and have the same set of dependencies, then
they will be loaded in the order they appeared in the defsystem
declaration. The problem occurs if the files *actually* depend on
each other, but the defsystem declaration doesn't reflect this. If
the files both happen to be loaded and both in the right order, there
is no problem, but the lack of correct dependency information will
cause very mysterious problems if one file is changed but the other
isn't re-loaded.
To fix this, I hacked my version of MK-DEFSYSTEM to randomize
the load order given the constraints. Now it is unlikely that a
dependency will be introduced and not caught fairly soon after.
Paul F. Dietz
> On 2005-03-08, rydis (Martin Rydstr|m) @CD.Chalmers.SE <ry...@CD.Chalmers.SE>
> wrote:
>
>>There are good reasons to have an unspecified argument evaluation
>>order. (Besides parallellism, it might also be useful for optimization
>>reasons.)
>
>
> Yes, Good point!
I consider non-specified evaluation order to be a TERRIBLE idea.
I have, over the past year, been testing the compilers on various lisp
implementations with a random test generator. It produces random (but
legal) lisp code, evals and compiles it, and looks for differences in
the result. Many bugs were found.
This is much harder to do if order of evaluation is unspecified.
Please, think of the testers, and don't put gratuitous nondeterministic
behavior into your specifications.
Paul
Geoffrey Summerhayes
"Paul F. Dietz" <di...@dls.net> wrote in message news:5aGdncmdmKv...@dls.net...
>
> I consider non-specified evaluation order to be a TERRIBLE idea.
>
> I have, over the past year, been testing the compilers on various lisp
> implementations with a random test generator. It produces random (but
> legal) lisp code, evals and compiles it, and looks for differences in
> the result. Many bugs were found.
>
> This is much harder to do if order of evaluation is unspecified.
>
> Please, think of the testers, and don't put gratuitous nondeterministic
> behavior into your specifications.
>
Just a few thoughts...
First, if there was an implementation that did random evaluation
order to improve testing, it would probably be selectable behaviour,
it's unlikely anyone would want to ship production code with that
feature(sic) enabled.
Second, if something is specified in the standard, a conforming
compiler/interpreter is bound by that standard and must behave
that way. Can't write portable code without it.
Third, if something is not specified in the standard, a conforming
program cannot rely on that behaviour. This is where a lot of posts
in C/C++ groups come from, there have been a few here as well.
(rplacd '(1 2 3) '(4 5 6)) as a fast and loose example.
So if a discrepency comes up with between an eval/compile test
- the specification says they will be different, no problem
- the specification allows for a difference but defines one fully,
no problem
- the specification says they will be the same, problem
- it's an allowed, documented extension to the language, problem
- unspecified behaviour, problem with the code generator e.g. n=n++;
Basic rule of survival, never write code in any language that relies
on unspecified behaviour, why should the tester be immune?
--
Geoff
Frode Vatvedt Fjeld
> There are good reasons to have an unspecified argument evaluation
> order. (Besides parallellism, it might also be useful for
> optimization reasons.)
An optimizing compiler should know how to determine if two argument
forms are dependent of eachother or not, and thereby whether their
evaluation order may be changed (or parallellized).
--
Frode Vatvedt Fjeld
Mario S. Mommer
David Steuber <da...@david-steuber.com> writes:
> True. A better example would have been:
>
> (foo (frob-x)
> (frob-y)
> (something-with-x-and-y))
>
> Not that I endorse that style of programming.
Why? Would god punish you if you depended on (specified, standard)
evaluation order?
There is nothing whatsoever wrong with that kind of code, IMO. Not in
CL.
Paul F. Dietz
> Basic rule of survival, never write code in any language that relies
> on unspecified behaviour, why should the tester be immune?
The problem is that this sort of thing makes it harder to generate
the test cases automatically. It may not be easy to recognize if
a given randomly generated input does violate the semantic constraints,
or so many of them may do so that you waste too much time generating
them and rejecting them.
It's also an unnecessary source of portability bugs for user programs,
and one more thing programmers have to keep in mind. We have small
minds, please don't clutter them.
Paul
Marco Antoniotti
Joe Marshall wrote:
> Marcin 'Qrczak' Kowalczyk <qrc...@knm.org.pl> writes:
>
>
>>t...@sevak.isi.edu (Thomas A. Russ) writes:
>>
>>
>>>The randomization of evaluation order at least makes the bugs appear
>>>sooner, so they can be eliminated.
>>
>>But they would be non-deterministic. It's much harder to fix
>>a non-deterministic bug which manifests only sometimes and in
>>various ways.
>
>
> But harder still to fix a bug that never manifests.
Does the bug exist? You should qualify your "never" :)
>
> To give an example, the standard version of MK-DEFSYSTEM uses a stable
> topological sort to determine the load order. If two files are not
> dependent upon each other, and have the same set of dependencies, then
> they will be loaded in the order they appeared in the defsystem
> declaration. The problem occurs if the files *actually* depend on
> each other, but the defsystem declaration doesn't reflect this. If
> the files both happen to be loaded and both in the right order, there
> is no problem, but the lack of correct dependency information will
> cause very mysterious problems if one file is changed but the other
> isn't re-loaded.
Yes. This may indeed happen. But in this case you "observed" a "bug
phenomenon" :)
> To fix this, I hacked my version of MK-DEFSYSTEM to randomize
> the load order given the constraints. Now it is unlikely that a
> dependency will be introduced and not caught fairly soon after.
This may be a good thing to do. Another way to fix this (and probably
easier) is to make sure that :dependes-on is inserted when missing,
making sure that the dependency is on the previous components.
Having said that, if people think that "randomized 'load' order" is a
good thing, I will include it in MK:DEFSYSTEM.
Cheers
--
Marco
Joe Marshall
> Joe Marshall wrote:
>> Marcin 'Qrczak' Kowalczyk <qrc...@knm.org.pl> writes:
>>
>>>t...@sevak.isi.edu (Thomas A. Russ) writes:
>>>
>>>
>>>>The randomization of evaluation order at least makes the bugs appear
>>>>sooner, so they can be eliminated.
>>>
>>>But they would be non-deterministic. It's much harder to fix
>>>a non-deterministic bug which manifests only sometimes and in
>>>various ways.
>> But harder still to fix a bug that never manifests.
>
> Does the bug exist? You should qualify your "never" :)
This is the developers `never': never reproducible when debugging,
but far too frequent when you have no time whatsoever to devote to
finding and fixing it.
>> To give an example, the standard version of MK-DEFSYSTEM uses a
>> stable
>> topological sort to determine the load order. If two files are not
>> dependent upon each other, and have the same set of dependencies, then
>> they will be loaded in the order they appeared in the defsystem
>> declaration. The problem occurs if the files *actually* depend on
>> each other, but the defsystem declaration doesn't reflect this. If
>> the files both happen to be loaded and both in the right order, there
>> is no problem, but the lack of correct dependency information will
>> cause very mysterious problems if one file is changed but the other
>> isn't re-loaded.
>
> Yes. This may indeed happen. But in this case you "observed" a "bug
> phenomenon" :)
>
>> To fix this, I hacked my version of MK-DEFSYSTEM to randomize
>> the load order given the constraints. Now it is unlikely that a
>> dependency will be introduced and not caught fairly soon after.
>
> This may be a good thing to do. Another way to fix this (and probably
> easier) is to make sure that :dependes-on is inserted when missing,
> making sure that the dependency is on the previous components.
Yes, but that defeats the purpose of having a dependency tree. If
each module depends on every module before it, then changing one
module causes a complete recompile of everything downstream regardless
of whether it needs it or not.
Duane Rettig
> Geoffrey Summerhayes wrote:
>
> > Basic rule of survival, never write code in any language that relies
> > on unspecified behaviour, why should the tester be immune?
>
> The problem is that this sort of thing makes it harder to generate
> the test cases automatically. It may not be easy to recognize if
> a given randomly generated input does violate the semantic constraints,
> or so many of them may do so that you waste too much time generating
> them and rejecting them.
It is hard not only on the tester, but the implementor as well; if
an implementation actively randomizes evaluation orders, and a test
turns up a failure due to evaluation order, how can it be reproduced
in order to debug it? Give me a hard, reproducible failure any day
over one that it intermittent...
--
Duane Rettig du...@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Bob Woodham
> allow evaluation being interleaved or parallel.
>
> I couldn't find this spelled explicitly in C or C++, it just follows
> from the fact that there is some unspecified order between evaluation
> of function arguments. In Scheme (R5RS) it is written explicitly:
>
> 4.1.3. Procedure calls
> [...]
> Note: Although the order of evaluation is otherwise unspecified,
> the effect of any concurrent evaluation of the operator and operand
> expressions is constrained to be consistent with some sequential order
> of evaluation. The order of evaluation may be chosen differently for
> each procecure call.
You are correct about Scheme. Thanks for elaborating (and for educating me).
The same note you quoted from R5RS is present in R4RS (I checked). I am
curious as to when/why this note was explicitly added to RnRS.
I went back to the original Scheme paper by Sussman and Steele (MIT AI Memo
349, December, 1975). The first sentence in the Abstract describes Scheme as
"...based on the lambda calculus... ...but extended for side effects,
multiprocessing, and process synchronization." The original Sussman and
Steele Scheme indeed had several primitives related to multiprocessing,
specifically CREATE!PROCESS, START!PROCESS, STOP!PROCESS and
EVALUATE!UNINTERRUPTIBLY. One of their motivations for inventing Scheme was
to be an experimental vehicle for exploring issues of "programming semantics
and style," including (I fuzzily recall) parallelism. I was disappointed that
this aspect of Scheme disappeared over the years as the language evolved. I
always assumed this had more to do with inadequate multiprocess support in the
underlying operating systems of the day than with programming language issues
per se.
An interpreter for Scheme (written in Maclisp) is given in the original paper.
An interpreter for Scheme (written in Scheme) is given in Manis and Little,
"The Schematics of Computation," an introductory text I have taught from.
I've had students modify (and experiment with) Scheme interpreters (for
pedagogic reasons). It is straight forward, for example, to implement a
dynamically scoped variant of a Scheme interpreter (and to compare this with
lexical scoping). I had imagined (well fanatasized would be more accurate)
implementing a parallelized (multiprocess) order of argument evaluation
variant (again, for pedagogic reasons). Now, thanks to you, I know this would
violate R5RS.
I don't have much more to say regarding C/C++. The answer we're seeking may
not be stated explicitly. Let me try, by way of example, to frame the
question. Suppose we have a function/procedure that takes two arguments.
Suppose also we have four distinct bells A, B, C and D. Evaluation of
argument 1 has the side effect of ringing bells A and C (in that order).
Evaluation of argument 2 has the side effect of ringing bells B and D (in that
order). With one sequential order of argument evaluation we would hear bells
A, C, B and D (in that order). With the other we would hear bells B, D, A and
C (in that order). An overlapping/parallel order of evaluation might cause us
to hear bells A, B, C and D (in that order). Your position is that this is
explicitly forbidden in C/C++ (as it is in Scheme).
I have no basis to dispute your position (except to wonder, as I do with
Scheme, why such prohibition is necessary).
Am I (still) missing something?
P.S. This discussion is now well off-topic for this thread and even for
this newsgroup. Perhaps we should take it off-line (or move it to
a different thread and/or newsgroup).
David Steuber
It's correct and portable code, but the implied side-effect nature of
it probably hinders maintenance. I certainly don't think it's a crime
to depend on specified evaluation order. The fact that in CL
evaluation order is specified means that you can take advantage of it
for code brevity (or other human-friendly reasons).
How often does this situation actually come up though? In most code,
all I'm caring about is the fact that the arguments to a function are
evaluated before the function call. This is probably a hold over from
my C habbit where evaluation order of function arguments was not
guaranteed.
I think the above example might be better if it was:
(let ((x (frob-x))
(y (frob-y)))
(foo x y (something-with-x-and-y x y)))
Geoffrey Summerhayes
"Duane Rettig" <du...@franz.com> wrote in message
news:4oedsw...@franz.com...
> "Paul F. Dietz" <di...@dls.net> writes:
>
>> Geoffrey Summerhayes wrote:
>>
>> > Basic rule of survival, never write code in any language that relies
>> > on unspecified behaviour, why should the tester be immune?
>>
>> The problem is that this sort of thing makes it harder to generate
>> the test cases automatically. It may not be easy to recognize if
>> a given randomly generated input does violate the semantic constraints,
>> or so many of them may do so that you waste too much time generating
>> them and rejecting them.
>
> It is hard not only on the tester, but the implementor as well; if
> an implementation actively randomizes evaluation orders, and a test
> turns up a failure due to evaluation order, how can it be reproduced
> in order to debug it? Give me a hard, reproducible failure any day
> over one that it intermittent...
>
Well, I'm not convinced that this particular feature would be
useful, but the idea is to raise the occurance of an intermittent
bug to the point it is noticable rather than giving the impression
that there is nothing wrong. Like the old trick in C of introducing
a version of realloc that always allocates in a different location
for debug builds.
Kind of academic anyway, implementations have enough problems
without this kind of thing being added to the toolkit.
--
Geoff
Duane Rettig
I would have no problem with such a feature if it could be
controlled, perhaps given a seed so that the pseudorandomness
could be reproduced on demand for debugging.
> Kind of academic anyway, implementations have enough problems
> without this kind of thing being added to the toolkit.
--
Damien Kick
> Bob Woodham wrote:
>
> > On 2005-03-08, rydis (Martin Rydstr|m) @CD.Chalmers.SE
> > <ry...@CD.Chalmers.SE> wrote:
> >
> > > There are good reasons to have an unspecified argument
> > > evaluation order. (Besides parallellism, it might also be useful
> > > for optimization reasons.)
> >
> > Yes, Good point! [...] There are few reasons for randomization for
> > the sake of randomization. However, what may appear to be
> > meaningless randomization may be the consequence of some activity
> > that is meaningful (like compiler optimization, as you point out).
> > [...] with gcc, the (perverse but simple) C expression
> >
> > n = n++;
> >
> > [produces] a different final assignment to the value of n
> > depending on the level of optimization chosen.
>
> I consider non-specified evaluation order to be a TERRIBLE idea.
I was interested to see some lively debate on the subject of the order
of the evaluation of arguments, with more than one claim that OOE
didn't make much difference to performance <http://tinyurl.com/6zkdz>
<http://tinyurl.com/5ex6z> (I know, I read it on usenet so it must be
true), appear in a thread <http://tinyurl.com/3ldu8> on
comp.lang.c++.moderated <pause to="wait for someone to make a snide
comment about C++">. Apparently not even the C/C++ community agrees
on the usefulness of unspecified argument evaluation order. Of
course, I realize that some consider C and C++ to be about as much a
part of the same community as is Scheme and Lisp, but I personally
think the fact that Stroustrup specifically mentions compatability
with C, i.e. "no gratuitous incompatibilities with C", was a design
goal for C++ <pause to="wait for flame fest to spawn as to what is and
is not actually gratuituos about various incompatibilities">.
Anyway...
Christopher C. Stacy
I haven't thought about this for more than 2 seconds,
but two obvious possibilities include:
1. Have a special variable *RANDOMIZE-LOAD-ORDER*
that the user could set. It could be either NIL,
a random seed. Maybe several variables like this.
2. Have seperate system operations, with corresponding
methods that are programmed to do the randomization.
These could be re-programmable by the user, and would
also be good places to put breakpoints or other hacks
in the course of figuring things out. Maybe these
methods are implemented by using the special variables
described above, and by calling the other operation methods.
Chris
Kent M Pitman
> rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:
>
> > > What strikes as perverse is to write code that depends upon the
> > > order of argument evaluation.
> >
> > Not when that order is specified (in the language or the
> > implementation). Why would it be?
>
> I was sort of wondering the same thing. Isn't something like:
>
> (if (foo) (bar) (baz))
>
> rather dependent on the order of evaluation?
I think the flaw happens when people learn one language by assuming its
definition is a dependent on the other. They are constantly afraid that
the [imagined] "truth" will suddenly out.
When I worked as Project Editor on ISO ISLISP, some in the German
group would veritably panic if I wrote "... will ..." and INSISTED
that I should change "will" to "shall". "What's the difference?" I
would ask. "They mean the same thing." Some time later, I was making
an abortive attempt to learn German, and I found out that in German,
"will" does not have the sense of certainty that it does in English.
I suddenly understood the source of their apprehension. (I guess they
assumed that since English probably got this word from German, we must
have taken the meaning with it, though we didn't. They had likely
been fearing a phantom capability of change in English that wasn't
really there. If you think of English as some kind of bastardized
German, then you'd easily worry that the truth about the Real Meaning
would somehow eventually come out. If you think of English as a first
class language in its own right, it's harder to make this mistake.)
I think that people who've worked in and accepted a language in which
control of "order of arg evaluation" has been yielded to the
compiler's whim, they find it hard to believe that others could not
only make this decision differently but also, importantly, not always
feel a weird sense of doubt or guilt like "maybe we made a bad
decision and we should yield this decision back to the compiler for
better performance". But the truth is, I've never found myself saying
"Damn, this code just can't be bummed enough by the compiler because
we made that regrettable decision to define order of arg evaluation".
Just the opposite, I've (a) never noticed any effect and (b) been
happy as a clam that I could read code in the order it's written and
expect it to evaluate just like that. It makes my normal programming
job easier. It makes macro writing easier. It makes porting a LOT
easier. I would never go back.
As a meta-observation about systems design in general, it's hard not
to feel that if two communities happily make a decision in opposite
ways, that it's not in some sense arbitrary. Perhaps there's even an
asymmetric meta-meta-theory that says that it's easier to feel
comfortable not relying on the system to allow the arbitrariness than
allowing it, since their code can't be broken by the arbitrary choice
being reversed. Maybe that makes some feel like they're compatible
with either lifestyle. But if all they're going to do in the world
where the arbitrary choice is not promised is never use it, they'll
never see the other side of the situation, which is that some
arbitrary things are just randomly useful. Perhaps someone who's used
to a spartan existence (e.g., lack of television) considers himself
compatible with either community, but I don't think they'll ever come to
really understand it until they understand how to appreciate the USE of
TV, not merely how to frown on its use, when they are in a community that
has it.
The other half of this, of course, is that if two communities are truly
different, sharing few designers and users, each going their own way
without fear of incompatibility with the other, as are the Scheme and Lisp
communities, or as are the German and English communities (or Spanish and
Portuguese or Italian, for another few examples), or so on, it's maybe
expedient to quick bootstrapping of a basic understanding to treat one as
a variant of the other, but deep understanding isn't going to come until
you can really feel that you can make subtle changes to the relationships
in one without perturbing your understanding of the other. So long as you
define your knowledge as a thin veneer of one over the other, you have to
worry that a change to your understanding of one will show through badly
into another, and it causes you to want to deny truths about one or the
other rather than admit that your representational system is a sham.
(Microsoft Word style sheets used to have this problem. Not sure if
they still do. By not having a way of making a style sheet that
distinguishes between "style X is based on Y, but property X is the
necessary opposite of Y, wanting to change in Y if X changes" and
"style X is based on Y, but property X is the accidental opposite of
Y, not wanting to change in Y if X changes", it was hard to edit either
X or Y in a way that was meaningful. Better to just define X and Y as
styles not based on each other, even though more bookkeeping was needed
in the case of coordinated changes.)
> Although I can see where you might be standing on shaky ground if you
> are doing foo bar baz for side effects in something like:
>
> (and (foo) (bar) (baz))
Here your bug is not relying on order of argument evaluation, but on
return value of something you're doing for side-effect.
> But even that can be perfectly fine.
Heh. Sometimes. Just to drive the point home, a pointer bakc to the late
1970's in Maclisp (pre Common Lisp), where I used to see a lot of:
(AND (SITUATION) (PRINT X) (NOT (TERPRI)) (PRINT Y) ...)
People did this because there was no WHEN and they were too lazy to write
a one-line WHEN macro.
I've got to say I never liked those (NOT (TERPRI))'s.
(Maclisp's PRINT always returned T and its TERPRI always returned NIL,
btw. It was considered too dangerous to efficiency to return the argument
of PRINT because it might not be heap-consed, and returning it might force
it to become so.)
Pascal Bourguignon
> [...]
Well, standards, and in particular RFC usually use SHALL instead of
WILL. I've allways felt the nuance, and indeed, shall sounds more
committing. Perhaps British English is still influenced by its German
origins. (I learned _British_ English as second language, American
English comes only 5th or 6th :-).
But on the other hand, since WILL is not used in the RFCs, it may be
because it's strictly equivalent to SHALL...
From RFC2822:
2.3 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described below.
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that
the definition is an absolute requirement of the specification.
2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.
3. SHOULD This word, or the adjective "RECOMMENDED", mean that
there may exist valid reasons in particular circumstances to
ignore a particular item, but the full implications must be
understood and carefully weighed before choosing a different
course.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean
that there may exist valid reasons in particular circumstances
when the particular behavior is acceptable or even useful, but the
full implications should be understood and the case carefully
weighed before implementing any behavior described with this
label.
5. MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because
a particular marketplace requires it or because the vendor feels
that it enhances the product while another vendor may omit the
same item. An implementation which does not include a particular
option MUST be prepared to interoperate with another
implementation which does include the option, though perhaps with
reduced functionality. In the same vein an implementation which
does include a particular option MUST be prepared to interoperate
with another implementation which does not include the option
(except, of course, for the feature the option provides.)
--
__Pascal Bourguignon__ http://www.informatimago.com/
I need a new toy.
Tail of black dog keeps good time.
Pounce! Good dog! Good dog!
Christopher C. Stacy
Duane Rettig
> David Steuber <da...@david-steuber.com> writes:
>
> > rydis (Martin Rydstr|m) @CD.Chalmers.SE writes:
> >
> > > > What strikes as perverse is to write code that depends upon the
> > > > order of argument evaluation.
> > >
> > > Not when that order is specified (in the language or the
> > > implementation). Why would it be?
> >
> > I was sort of wondering the same thing. Isn't something like:
> >
> > (if (foo) (bar) (baz))
> >
> > rather dependent on the order of evaluation?
>
> I think the flaw happens when people learn one language by assuming its
> definition is a dependent on the other. They are constantly afraid that
> the [imagined] "truth" will suddenly out.
>
> When I worked as Project Editor on ISO ISLISP, some in the German
> group would veritably panic if I wrote "... will ..." and INSISTED
> that I should change "will" to "shall". "What's the difference?" I
> would ask. "They mean the same thing." Some time later, I was making
> an abortive attempt to learn German, and I found out that in German,
> "will" does not have the sense of certainty that it does in English.
> I suddenly understood the source of their apprehension. (I guess they
> assumed that since English probably got this word from German, we must
> have taken the meaning with it, though we didn't.
Actually, we did; if you look at Old and Middle English texts, and
writings even as late as King James and Shakespeare, you find that
the word "will" (and even still today with its past tense "would")
really means "desire", more so than it provides a plan of action
or a requirement. Perhaps the difference has gotten lost in the
American "can-do" culture, where there is only a small step from a
desire to do something to a plan or an order to do that thing.
Note that we still tend to use shall exclusively in legal documents,
and it's always a "Last Will and Testament", which word only means
sense as translated as "desire" - a dead person can no longer plan
a future action...
> They had likely
> been fearing a phantom capability of change in English that wasn't
> really there. If you think of English as some kind of bastardized
> German, then you'd easily worry that the truth about the Real Meaning
> would somehow eventually come out.
It's more likely that the Real Meaning was in its etymology, and we
Americanms (at least) tend not to see that etymology because the
usage is so deeply ingrained.
> If you think of English as a first
> class language in its own right, it's harder to make this mistake.)
As one who thinks of English as a first class language, but not in
its own right (i.e. it has had help from German and all Latin
languages), I will [sic] continue to make that mistake.
How does this relate to argument order? I don't know, but I do agree
with your general take that the perception one has about both issues
is closely tied to the experiences one has had with each, and not
with its wording.
Kent M Pitman
> How does this relate to argument order? I don't know,
Because it goes to the question of whether you believe Lisp has
accidentally/temporarily/foolishly forgotten its roots in "order of
arguments doesn't matter" and temporarily deviated, or whether it's
comfortable in its new shoes.
Karl A. Krueger
> Actually, we did; if you look at Old and Middle English texts, and
> writings even as late as King James and Shakespeare, you find that
> the word "will" (and even still today with its past tense "would")
> really means "desire", more so than it provides a plan of action
> or a requirement.
In modern English, "will" and "shall" also differ in their meaning when
used in the first and third person. One classic example is the
difference between the despairing swimmer and the insistent suicide:
"I shall drown; no one will save me!"
"I will drown; no one shall save me!"
--
Karl A. Krueger <kkru...@example.edu> { s/example/whoi/ }
Duane Rettig
> Duane Rettig <du...@franz.com> writes:
>
> > How does this relate to argument order? I don't know,
>
> Because it goes to the question of whether you believe Lisp has
> accidentally/temporarily/foolishly forgotten its roots in "order of
> arguments doesn't matter" and temporarily deviated, or whether it's
> comfortable in its new shoes.
Well, for me the jury is still out.
Actually, the analogy is exactly opposite from what it is analogizing:
the trend in shall/will in American English has moved toward _less_
distinction and precision, and the mandate from Common Lisp is a move
toward _more_ precision.
I assume that such greater precision is a Good Thing. I'm sure Paul
Dietz had a lot of fun coming up with tests for argument-ordering,
and it has been interesting trying to figure out how particular
results have been expected. However, although they make good Test
Suite code, in no way would I call those tests good coding style
for general programming. Of course, such is the naature of testing,
but I think you have to look at some of those tests to understand
what I mean...
Alan Crowe
> There are good reasons to have an unspecified argument
> evaluation order.
I've seen this stated, often on high authority, but I am at
a loss to imagine what those reasons might be.
I can see the disadvantages easily enough. One has some code
(setf status (progn (beginning)(middle)(end)))
I assume that no-one will complain about my style if the
correct operation of my program depends on BEGINNING running
first and END running last.
However it feels very natural to decide to change BEGINNING
and MIDDLE to return useful status information and alter the
code to
(setf status (list (beginning)(middle)(end)))
It is distressing to have to re-write this as
(setf status (let ((temp1 (beginning))
(temp2 (middle))
(temp3 (end)))
(list temp1 temp2 temp3)))
It is easy to imagine code that starts out with
(progn (beginning)(middle)(end))
and has two programmers working on it.
One programmer decides that since they are sequenced by
progn he can add code that writes log files or creates an
audit trail.
Meanwhile the other programmer decides that since the
correct operation of the program does not depend on the
order he can change it to
(list (beginning)(middle)(end))
So one ends up with the order of the log files being
scrambled when the the code is ported!
There are all sorts of ways that a dependence on argument
orded can sneak into code. Now I've read Dijkstra and the
authentic message of the man himself is ``horses for
courses'' and ``belt and braces''. You are supposed to read
his book on how to prove code correct, and then read other
authors' books on how to test code, the then do both.
A language designer should take into account the needs of
both the prover and the tester.
If one suspects that ones growing pile of C code is
accumulating little lurking dependencies on argument order,
how is one to test for this? If I had to do this for real I
think my best plan would be to write a C to CL translator,
then combine CL's left to right order with the flexibility
of a home grown translator to give me controlled variation
of the order, so that I can re-run my test suite with
various orders.
Maybe I could parse the C and re-emit it with added
temporary variables to force one order or another.
One encounters various rules of thumb about bugs getting
more and more expensive to fix, the later you discover
them. Having an unspecified argument evaluation order seems
likely to produce lurking bugs that come out at really
expensive times such as porting your code to a new platform.
The advantage I've seen claimed in print is that
When side effects takes place is left to the discretion
of the complier, since the best order strongly depends on
machine architecture.
Well, way back when I wrote lots of 6800 and 6809 assembler,
I would sketch out my pseudo-code with pencil and paper then
set about coding it. If I wanted to call a function I would
assemble the arguments pushing them onto the stack as I
went. I don't think I ever bothered skipping the stack on to
write a late argument early.
I do remember writing routines that returned variable
numbers of arguments. Learning CL after working with C
brought back happy memories. I could return variable numbers
of arguments, just like I could in assembler. I could depend
on the argument evaluation order, just like I could when I
coded the pushing of the arguments myself. Ahh! the pleasures
of a close-to-the-metal language, not one of those
airy-fairy abstract languages like C :-)
So I'm unimpressed by the notion that a free argument
evaluation order is useful for optimization. It seems
obvious to me that the advantage cannot be very great.
More to the point, it must strike every-one that the
advantage is small beer for the following reason of internal
consistancy.
If the statement in your C code that
x = f() + g();
will not do because g might run first, you can always say
{ int temp;
temp = f();
x = temp + g();}
Well yes. But you never get advice that you must strip out
temporary variables for performance reasons. No-one ever
says "watch out for the pattern
x = f();
y = x + g();
your code will run much faster when you write
y = f() + g();
and the compiler is free to optimise whether f or g runs first."
The story about the best order /strongly/ depending on
machine architecture only comes up in apologies for the
worries heaped on the programmer by unspecified argument
evaluation order. Would any-one really build a computer
architecture in which you risked a big preformance hit if
you forced evaluation order with a temporary variable? Of
course not. So the language designer is not taking any real
risk with the performance potential of his language when he
specifies argument evaluation order.
I would love to know how the notion of leaving the argument
evaluation order unspecified gained such traction.
Alan Crowe
Edinburgh
Scotland
Gorbag
"Kent M Pitman" <pit...@nhplace.com> wrote in message
news:u1xanr...@nhplace.com...
> When I worked as Project Editor on ISO ISLISP, some in the German
> group would veritably panic if I wrote "... will ..." and INSISTED
> that I should change "will" to "shall". "What's the difference?" I
> would ask. "They mean the same thing."
Actually, no, at least not if you were taught "the King's English" in grade
school as I was.
"I shall" is equivalent to "I intend to at the current time."
"I will" is equivalent to "I promise to."
That is, in first person, "shall" is weaker, intentionally, then "will."
The reverse is true, however, in second and third person.
That is, "I shall" is equivalent to "you will" and "he will"
while "I will" is equivalent to "you shall" and "he shall"
from an intentional strength point of view.
Source:
http://www.bartleby.com/116/index.html
Juliusz Chroboczek
>> order.
> I can see the disadvantages easily enough.
Unspecified evaluation order is a pain in languages without macros --
it prevents you from writing PROG1.
> (setf status (list (beginning) (middle) (end)))
(defmacro s-list (&rest forms)
(let ((symbols (mapcar #'(lambda (f) (gensym)) forms)))
`(let ,symbols
,@(mapcar #'(lambda (s f) `(setq ,s ,f)) symbols forms)
(list ,@symbols))))
> I would love to know how the notion of leaving the argument
> evaluation order unspecified gained such traction.
Because people like short and sweet language definitions. Less work
for the implementor, fewer pages to read for the user.
Juliusz
Adrian Kubala
> In modern English, "will" and "shall" also differ in their meaning when
> used in the first and third person. One classic example is the
> difference between the despairing swimmer and the insistent suicide:
>
> "I shall drown; no one will save me!"
> "I will drown; no one shall save me!"
Which is which? To my American ears, the meaning is not clear without
context but I'd probably assume that in both cases, "will" = intent and
"shall" = obligation, and in neither case is "will" predictive as in "It
will rain tomorrow."
To be at least a little on topic, I think "Implementors WILL ..." sounds
silly and "Implementors SHALL ..." sounds pompous -- what's wrong with
"must"?
Pascal Bourguignon
> Karl A. Krueger <kkru...@example.edu> schrieb:
> > In modern English, "will" and "shall" also differ in their meaning when
> > used in the first and third person. One classic example is the
> > difference between the despairing swimmer and the insistent suicide:
> >
> > "I shall drown; no one will save me!"
> > "I will drown; no one shall save me!"
>
> Which is which? To my American ears, the meaning is not clear without
> context but I'd probably assume that in both cases, "will" = intent and
> "shall" = obligation, and in neither case is "will" predictive as in "It
> will rain tomorrow."
To an European, the meaning is clear.
If you will, just substitute want for will!
> To be at least a little on topic, I think "Implementors WILL ..." sounds
> silly and "Implementors SHALL ..." sounds pompous -- what's wrong with
> "must"?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Cats meow out of angst
"Thumbs! If only we had thumbs!
We could break so much!"
Kent M Pitman
> Adrian Kubala <adria...@sixfingeredman.net> writes:
>
> > Karl A. Krueger <kkru...@example.edu> schrieb:
> > > In modern English, "will" and "shall" also differ in their meaning when
> > > used in the first and third person. One classic example is the
> > > difference between the despairing swimmer and the insistent suicide:
> > >
> > > "I shall drown; no one will save me!"
> > > "I will drown; no one shall save me!"
> >
> > Which is which? To my American ears, the meaning is not clear without
> > context but I'd probably assume that in both cases, "will" = intent and
> > "shall" = obligation, and in neither case is "will" predictive as in "It
> > will rain tomorrow."
>
> To an European, the meaning is clear.
>
> If you will, just substitute want for will!
Yes, I've come to understand that, and don't dispute it.
But you should understand just as clearly that this is a major gap
between US and British English.
> > To be at least a little on topic, I think "Implementors WILL ..." sounds
> > silly and "Implementors SHALL ..." sounds pompous -- what's wrong with
> > "must"?
IMO, People in the US treat shall and will as synonyms, and give them
both the meaning of shall, but in any case, whether they do or don't,
they don't think they're changing the meaning, mostly just the tone,
by choosing the alternative. I think most Americans think "shall"
sounds stilted and formal--the kind of thing John Kerry would say
("this is something up with which I shall not put"... with apologies
to Churchill, who I guess originated that quote). And "will"
sounds friendly and folksy--the kind of thing George Bush would
realize will win more votes ("this is something I just won't put up
with").
George Neuner
<adria...@sixfingeredman.net> wrote:
>Karl A. Krueger <kkru...@example.edu> schrieb:
>> In modern English, "will" and "shall" also differ in their meaning when
>> used in the first and third person. One classic example is the
>> difference between the despairing swimmer and the insistent suicide:
>>
>> "I shall drown; no one will save me!"
>> "I will drown; no one shall save me!"
>
>Which is which? To my American ears, the meaning is not clear without
>context but I'd probably assume that in both cases, "will" = intent and
>"shall" = obligation, and in neither case is "will" predictive as in "It
>will rain tomorrow."
I think your interpretation is basically correct.
English is an abused puppy. My pet peeve is the substitution of
"since" for "because". I can't read "since" without looking for a
time reference.
>To be at least a little on topic, I think "Implementors WILL ..." sounds
>silly and "Implementors SHALL ..." sounds pompous -- what's wrong with
>"must"?
Elephants must 8-)
I personally don't think "shall" is pompous, but it has fallen out of
general use. IMO, the best way to phrase the above would be
"Implementors are required ...".
George
--
for email reply remove "/" from address
Joerg Hoehle
> If each module depends on every module before it, then changing one
> module causes a complete recompile of everything downstream regardless
> of whether it needs it or not.
But that'S the curse of any defsystem/Makefile
How could you escape it?
How can you tell to the system
a) "listen, I've made this change to the file, but be assured that
it's only a local change, you need not recompile all and
everything"?
b) "ok, recompile stuff in this component, but it's internal only so
there's no need to recompile other entities"
c) "well recompile and reload really all dependents"
Typically, all defsystem sees is timestamps, and it does not know how
to choose among a) b) or c).
Sometimes I wished I had 2 system definitions for the same system: one
"development style" which many dependencies, and one "user style"
which would mostly presume locality of changes.
Last time I felt a need for this was when modifying code in one of
cl-uffi, cl-sql or cl-sql-xyz.
Did anybody else feel like a need for this?
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
Christophe Rhodes
> Did anybody else feel like a need for this?
Yeah. One way to achieve something like it might be to use version
numbers: not only does a system have internal dependencies noted, it
has versioned external dependencies, which are assumed to be satisfied
if, for instance, the instance of the depended-on system present has
exactly the same major number and a greater minor number.
This would allow a distinction between implementation change and
interface change, but of course it means that system definitions would
be subject to non-local effects if they are distributed...
Christophe
Marcin 'Qrczak' Kowalczyk
> But that'S the curse of any defsystem/Makefile
> How could you escape it?
>
> How can you tell to the system
>
> a) "listen, I've made this change to the file, but be assured that
> it's only a local change, you need not recompile all and
> everything"?
> b) "ok, recompile stuff in this component, but it's internal only so
> there's no need to recompile other entities"
> c) "well recompile and reload really all dependents"
It can be solved by a Lisp compiler: it should produce an "interface"
file which includes the information derived from a module which
influences the compilation of other modules which depend on it. Other
modules don't load a module directly but read its interface file.
The compiler should ensure that the file is not physically rewritten
if its contents don't change after recompilation.
Some compilers of other languages do a similar thing, e.g. Glasgow
Haskell Compiler. And in C and C++ people write the interface files by
hand.
This doesn't distingiush your b) from c), but it I think it's good
enough in practice.
The only caveat with marrying it with 'make' is that after some
changes 'make' might keep trivially "recompiling" a module (executing
a null command). This adds a minimal overhead, and prevents a message
that nothing had to be remade.
--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/