In article <b9dm5g$59t0...@midnight.cs.hut.fi>, Nikodemus Siivola
<tsiiv...@kekkonen.cs.hut.fi> wrote: > How many times have people explained this to you? I've lost count. Grahams > book was published *before* there was an ANSI standard.
I am well aware of that. His "old" book is still quite useful for learning purposes.
I am not at all convinced that using "undefined behavior" is as bad a thing as some make it out to be.
After all, Paul Graham must have known that the behavior of variables at the time of his book work was "undefined behavior", even at that time. Despite all that, he still used "undefined behavior".
Once a programmer demonstrates to his clients that a problem is "solvable" by using CL "behavior", undefined or otherwise, it becomes a lot easier to gain funding for the project in order to re-code the "bandit-Lisp" into production code that is reliable.
The clients have the priceless knowledge that their funds will not be wasted on a project that has no chance of success, because the Lisp version works in so far as cracking the problem is concerned.
Mark Conrad wrote: > In article <lyd6it63bq....@cartan.de>, Nils Goesche <car...@cartan.de> > wrote:
> > Heh. Looks like a bug to in MCL to me.
> Anything is possible in that piece of code. I will take the easy way > out and use eval-when, as long as it works:
If it works for your project in your Lisp that is all that really matters.
It depends on wheather or not you want to make it portable. If you are happy with the app. running in MCL you can leave it just the way it is, even with the 'undefined behavior' because it is working in MCL.
If some one else should want to port it to a different CL compiler thay might have to make changes to get it to run.
However it is not wrong to relie on 'undefined behavior' -- it is the same as reling on an implementation specific function such as streams, or a web server.
If the code works, undefined or not, use it. :)
Seasoned Users Note:We should not try to scare a CL newbe away from the lang. we're having enough troble attracting them to Lisp in the first place.
& what does jumping off the Brooklyn Bridge have to do with barrowing some of Paul Garhams CL code from 'On Lisp.'
Even though commonp and define-setf-method are no longer ANSI it is not wrong for a user to write code to implement them--in fact it could be easier to add two functions, that it would be to rewrite all the code that depends on them. I just chose those funcs. of the top of my head /w no rhyme or reason.
> If it works for your project in your Lisp that is all that really matters.
> It depends on wheather or not you want to make it portable. If you are happy > with the app. running in MCL you can leave it just the way it is, even with > the 'undefined behavior' because it is working in MCL.
In the version of MCL he currently uses, that is. And unless he does anything else that might cause this version to behave differently.
> Seasoned Users Note:We should not try to scare a CL newbe away from the > lang. we're having enough troble attracting them to Lisp in the first place.
Thanks for educating us. I'm sure letting newbies run in all sorts of needless trouble will do wonders for Lisp popularity.
> Thanks for educating us. I'm sure letting newbies run in all sorts of > needless trouble will do wonders for Lisp popularity.
> Regards > Henrik
I think asking him if he'd jump off a bridge with Paul Garham was going a little too far. He already decided that he's going to write his program--I think we should help him.
a.) Teach him about #+ #- reader macros.
b.) Teach him how to add the feature he needs to Lisp so it is not undefined.
c.) Teach him how to check for the error so he can run his code.
d.) Show him an other way to implement continuations in Lisp because that is what he wants to do. If he knew of a better or safer way to do it--I'm sure he would.
But it would be a waste of bandwidth to try to talk him out of doing what he already decided he was going to do. We warned him it might be dangerous--but he might have 2 find out 4 himself.
(Debugging the code and getting it to run might even be his best teacher.)
Someone should tell him what might work, not why his code might not--because that would help him more
----------
#+(MCL) ;; informs user that code runs in MCL ;; but other code might be needed for other CLs. (eval-when (:load-toplevel :execute) (setf (symbol-value '%cont%) (lambda (&rest args) (if (cdr args) args (car args)) )))
#-(MCL) (+ 3 4) ;; does not get evaluated in MCL.
The #+ & #- macros are used to write non-portable code in a portable way. The non-portable parts are written with the #- or #+ reader function to make sure the right Lisp uses the right functions.
I don't know much about #- or #+ except that thay could be used to make your code run in all CLs. Someone on this list might know.
In article <080520031323350888%nos...@iam.invalid>, Mark Conrad <nos...@iam.invalid> wrote:
> In article <b9deds$o5...@f1node01.rhrz.uni-bonn.de>, Pascal Costanza > <costa...@web.de> wrote:
> > Section 1.5 of the HyperSpec tells you _exactly_ what you can and must > > not assume with regard to portability of your programs across conforming > > implementations. See > > http://www.lispworks.com/reference/HyperSpec/Body/01_e.htm
> Do you happen to know where I can buy a hardcopy of the HyperSpec.
There are no hardcopies of the HyperSpec available. You can get hardcopies of the ANSI spec, but they are very expensive.
> Just curious if a hardcopy is available, and where.
> My Mac, running OS 10.2.4 (so-called "OS X") - froze up when I was > using the downloadable version. That is the first time in six months > that OS X froze on anything.
I am also running OS X and don't have this problem. Just try again.
Mark Conrad <nos...@iam.invalid> writes: > In article <20030508063523.A20...@mapcar.org>, Matthew Danish > <mdan...@andrew.cmu.edu> wrote: > > Prove me wrong.
> Why should I bother. That is a bunch of work.
Because this is how discussions between *adults* work. And yes it is a lot of work to do this, that is how knowledge is produced.
> > Or stop making broad statements about an issue which you are > > clueless about, at least in a forum that better-informed people are > > reading.
> I most certainly will not! Making those broad statements has a decided > benefit for me. If my statement is wrong, I get ample replies > informing me exactly how the cookie crumbles.
You do not seem to understand that the rest of us are not here for your pleasure. You are not the center of creation and you should not act like it
> From those replies, I can ignore the hate mongers, and sift out > knowledge that is understandable to me.
At least you admit you do not understand the correct answers that people have posted to your questions, you only understand the answers that agree with your preconceived ideas. This is so stupid when you consider that even you know that you do not know what you are talking about.
> Why should I abandon such a good learning tool.
Because you do not learn.
> Other Lisp newbies won't be influenced by my remarks, because I have > stated up front that I am a Lisp newbie also, many times.
From your observed behavior I am leaning more towards fool.
> My "clueless" broad remarks merely reflect the present stage of my > understanding, which is subject to daily change and improvement.
> That is why I get a kick out of those guys who dig up old erroneous > remarks of mine, that I have long since rejected as wrong, in their > vain efforts to discredit me.
No one is trying to discredit you, you are doing an excellent job by your self.
> I just ignore them, they obviously have some sort of ego thing where > they feel the need to look clever-by-comparison to a newbie.
Well I am beginning to think my mouse pad may be smarter then you, just because it has never talked to me.
> If you can't stand the heat in the "clueless" kitchen, stay out.
Pascal Costanza <costa...@web.de> writes: > In article <080520031323350888%nos...@iam.invalid>, > Mark Conrad <nos...@iam.invalid> wrote:
> > Do you happen to know where I can buy a hardcopy of the HyperSpec.
> There are no hardcopies of the HyperSpec available. You can get > hardcopies of the ANSI spec, but they are very expensive.
You can get the Postscript files of the latest draft (which IIRC has the same contents as the final ANSI spec and only differs with respect to formatting) and print them yourself. See the thread "HyperSpec in other formats" for URLs.
Or you can buy a copy of CLtL2 and "convert" it to ANSI CL:
(Of course this is not the same as the ANSI spec but it's a good start and you'll most likely learn something while you do that. I'm going to do it this weekend... :)
> > If you can't stand the heat in the "clueless" kitchen, stay out.
> Do you see what happens when Erik goes away???
Remember Ilias? He took enormous amounts of abuse and didn't go away. He disappeared when people stopped feeding him. If you think flames help, go look at sci.math and witness how utterly useless they can be.
Marc Spitzer <mspit...@optonline.net> writes: > Do you see what happens when Erik goes away???
Yeah. As much time and effort is spent on flaming insensitive, abusive, selfish jerks that seem unwilling to do the world a favour by breaking both wrists and dying obscure unobserved deaths as ever was, but now the load is spread more equitably than it used to be, and there's no secondary "why is Erik being mean to me" thread that also needs killing.
David Steuber <david.steu...@verizon.net> writes: > Matthew Danish <mdan...@andrew.cmu.edu> writes:
> > For all you know, typing "(setq a 1)" into a freshly loaded Lisp could cause > > demons to fly out of your nose!
> That would indeed be a most unexpected behavior. I think something > like beer or coffee would have a higher probability of flying out of > the nose, with devestating effects to a computer keyboard.
> > > Section 1.5 of the HyperSpec tells you _exactly_ what you can and must > > > not assume with regard to portability of your programs across conforming > > > implementations. See > > > http://www.lispworks.com/reference/HyperSpec/Body/01_e.htm
> > Do you happen to know where I can buy a hardcopy of the HyperSpec.
> There are no hardcopies of the HyperSpec available. You can get > hardcopies of the ANSI spec, but they are very expensive.
You can also buy a PDF of the ANSI spec from INICTS for a mere $18 and however long it takes to download (it's pretty big.) The license allows you to make a "copy" for "backup" purposes. Dunno if that technically includes printing out a hardcopy.
The intellectual level needed for system design is in general grossly underestimated. I am convinced more than ever that this type of work is very difficult and that every effort to do it with other than the best people is doomed to either failure or moderate success at enormous expense. --Edsger Dijkstra
> > A toplevel SETQ on a symbol that has not been > > DEFVARed has no defined meaning.
> It still has to act in the program in only one of two ways, either as > if it is dynamically-scoped or lexically-scoped.
The following are examples of reasonable and compliant behaviour:
1 > (setq foo 4) 4 2 > foo Error: The variable FOO is unbound.
1 > (setq bar 4) Error: Attempt to bind undeclared variable BAR
The following are still examples of compliant behaviour, though more inconvenient:
1 > (setq foo 4) Error: Segmentation fault (lisp freezes and you must reboot)
1 > (setq foo 4) 4 2 > (+ 5 foo) 37 3 >
Undefined means, hmm, not defined. Which means it isn't defined what will happen. Which means don't count on anything. Which means if you write your code this way, don't come work for me.
> > > Hope this explains what is going on -
> > It sure explains that you don't pay attention to anything you don't > > want to hear.
> Of course not, neither do you.
Ignoring what you don't want to hear is not a good way to learn anything, nor is it the most common way. I know it is a tendency we all share, but fight it, don't boast about it!
Every time my Windows session crashes with a blue screen full of giberish, I can hear some code monkey in the Redmond dungeons saying to himself, "hmm, it works right now on my machine, that's all that really matters"
Daniel Barlow wrote: > Marc Spitzer <mspit...@optonline.net> writes:
>>Do you see what happens when Erik goes away???
> Yeah. As much time and effort is spent on flaming insensitive, > abusive, selfish jerks that seem unwilling to do the world a favour by > breaking both wrists and dying obscure unobserved deaths as ever was,..
not. nonerikkians, upon working out that positive articles are lost on their misbegotten correspondents, simply offer no more help. aside: congrats to mark conrad for being harder to recognize by the CLL immune system than many predecessor infections. what is the sound of one troll clapping? They are gone overnight when the last CLLer (god bless their faith in humanity and their own powers of persuasion) gives up on them.
erik, having made the same determination, spewed abuse until the idiots worked out that only erik (the black hole into which every troll got sucked) was ever going to respond to them. then they went away. but that takes longer. so it is a lot more than "as much".
for those of you who like math in a dissertaion: erik got to his conclusions much faster (without loss of accuracy) than have nonerikkians recognized asininity, but that edge in performance is lost many times over in the amount of time it takes for idiots to recognize the futility of perpetuating any CLL thread.
that is the flaw in erik's strategy for driving trolls away: it relies for its effectiveness on the wit of trolls. uh-oh...
--
kenny tilton clinisys, inc http://www.tilton-technology.com/ --------------------------------------------------------------- "Everything is a cell." -- Alan Kay
Daniel Barlow <d...@telent.net> writes: > Marc Spitzer <mspit...@optonline.net> writes:
> > Do you see what happens when Erik goes away???
> Yeah. As much time and effort is spent on flaming insensitive, > abusive, selfish jerks that seem unwilling to do the world a favour by > breaking both wrists and dying obscure unobserved deaths as ever was, > but now the load is spread more equitably than it used to be, and > there's no secondary "why is Erik being mean to me" thread that also > needs killing.
Kenny Tilton <ktil...@nyc.rr.com> writes: > Daniel Barlow wrote: > > Marc Spitzer <mspit...@optonline.net> writes:
> >>Do you see what happens when Erik goes away??? > > Yeah. As much time and effort is spent on flaming insensitive, > > abusive, selfish jerks that seem unwilling to do the world a favour by > > breaking both wrists and dying obscure unobserved deaths as ever was,..
> not. nonerikkians, upon working out that positive articles are lost on > their misbegotten correspondents, simply offer no more help. aside: > congrats to mark conrad for being harder to recognize by the CLL > immune system than many predecessor infections. what is the sound of
I do not think that is fair to all the other trolls, back then Erik was part of the defense.
> one troll clapping? They are gone overnight when the last CLLer (god > bless their faith in humanity and their own powers of persuasion) > gives up on them.
> erik, having made the same determination, spewed abuse until the > idiots worked out that only erik (the black hole into which every > troll got sucked) was ever going to respond to them. then they went > away. but that takes longer. so it is a lot more than "as much".
> for those of you who like math in a dissertaion: erik got to his > conclusions much faster (without loss of accuracy) than have > nonerikkians recognized asininity, but that edge in performance is > lost many times over in the amount of time it takes for idiots to > recognize the futility of perpetuating any CLL thread.
> that is the flaw in erik's strategy for driving trolls away: it relies for > its effectiveness on the wit of trolls. uh-oh...
Kenny Tilton <ktil...@nyc.rr.com> writes: > Daniel Barlow wrote: > > Marc Spitzer <mspit...@optonline.net> writes:
> >>Do you see what happens when Erik goes away??? > > Yeah. As much time and effort is spent on flaming insensitive, > > abusive, selfish jerks that seem unwilling to do the world a favour by > > breaking both wrists and dying obscure unobserved deaths as ever was,..
> for those of you who like math in a dissertaion:
[ ooh ooh! er, so long as there aren't Greek letters... ]
> erik got to his conclusions much faster (without loss of accuracy) > than have nonerikkians recognized asininity, but that edge in > performance is lost many times over in the amount of time it takes > for idiots to recognize the futility of perpetuating any CLL thread.
[ awright, no Greek! ]
My gut impulse was to argue against "without loss of accuracy", but then I realized it's probably true. It's not that he didn't have false positives, but every group of people will, too. I'm thinking of Erann Gat[*] here -- he wasn't quite driven off by Erik -- but a slightly worse [ (signal/noise) / thick-skin ] version of him probably would have been. But then, any community will drive some valuable people off.
[*] Sorry Erann for using you personally as an example here. Hopefully you won't take offense to either (a) not getting along well with Erik; nor (b) being human [ie, a non-infinite signal/noise ratio].
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
On Thu, May 08, 2003 at 08:22:25PM +0000, Mark Conrad wrote: > In article <20030508063523.A20...@mapcar.org>, Matthew Danish > <mdan...@andrew.cmu.edu> wrote: > > Or stop making broad statements about an issue which you are > > clueless about, at least in a forum that better-informed people are > > reading.
> I most certainly will not! Making those broad statements has a decided > benefit for me. If my statement is wrong, I get ample replies > informing me exactly how the cookie crumbles.
This is fine. What's the problem is when you repeat those wrong statements even after you have been corrected. This shows that you do not learn, and that is what is causing people to become angry at you.
Will you learn this?
-- ; Matthew Danish <mdan...@andrew.cmu.edu> ; OpenPGP public key: C24B6010 on keyring.debian.org ; Signed or encrypted mail welcome. ; "There is no dark side of the moon really; matter of fact, it's all dark."
In article <skzua.5525$qH6.2...@news02.roc.ny.frontiernet.net>, Franz
Kafka < @> wrote: > If the code works, undefined or not, use it. :)
I intend to, as a learning vehicle.
Thanks very much for your kindly post. Such posts are becoming so rare lately that I am really learning to appreciate the few that I get.
> It depends on wheather or not you want to make it portable.
I had hopes of doing that, however other posters have presented good reasons why trying to port "undefined behavior" might not work.
Usually their reasons were buried in their posts amid abusive remarks to me, so decided not to give them the satisfaction of knowing that their reasons for not using "undefined behavior" were being taken seriously by me.
> However it is not wrong to rely on 'undefined behavior' -- it is the > same as relying on an implementation specific function such as streams, > or a web server.
I agree wholeheartedly. As I tried to point out to others, Paul Graham was well aware that he was using "undefined behavior", even in 1994 when his book was published, before the half-vast "fix" of eval-when ever became part of the ANSI standard.
You realize of course, that you are letting yourself in for attack by others by agreeing with me on these points. I hope you have a thick skin. ;-)
> If some one else should want to port it to a different CL compiler thay > might have to make changes to get it to run.
I *would* like to be able to post some code about learning to use Paul Graham's continuations, for the benefit of other newbies who might be interested in learning how to use those continuations in ANSI CL.
Graham's macros to implement continuations rely on macros and closures, which *are* "defined behavior in ANSI Commom Lisp.
The only thing unusual in Graham's code is that he relies on a toplevel variable named "*cont*" to *not* be a dynamically-scoped variable anywhere in his code for implementing continuations.
That variable has to "act like" a lexically-scoped variable, in order for Graham's continuations to work.
If interested newbies can ensure that "*cont*" works that way, all the rest of Graham's code should present no problem to them. (other than the usual problems of handling macros and closures)
In article <b9eucq$9s...@otis.netspace.net.au>, Coby Beck
<cb...@mercury.bc.ca> wrote: > Ignoring what you don't want to hear is not a good way to learn anything, > nor is it the most common way. I know it is a tendency we all share, but > fight it, don't boast about it!
I ignored it because it did not make any sense to me.
When something does not make sense, I tend to boast about being clever enough to spot it as not making sense.
Now I am an admitted newbie to all this *very* confusing Lisp stuff, so a lot of things don't make sense to me.
For that matter, some of the things I brought up in past threads did not make sense to others who have a lot more experience than I do, namely whether or not "binding" refers to a location in memory, or a value, or both.
Because of obvious complex issues like the above, CL is particularly hard to understand. For example, try to steer a newbie to a book that will explain the the complex function "eval-when" to them in a manner they can understand. Just for starters, none of my CL tutorial books address that function, much less explain how it works.
I don't appreciate the abuse being heaped upon my because of my stubborn refusal to change my opinion about "undefined behavior", when no valid reason so far has led me to consider changing.
If this is the way the CLL newsgroup members treat newbies, I see no reason whatever to study Lisp. I can't pick up these complex points from the recommended textbooks.
Your recent post comes closest to changing my present opinion about "undefined behavior", which none of the other abusive posters have been able to do.
They did not bother to do what you did, namely post example code like the following:
> The following are still examples of compliant behaviour, though more > inconvenient:
> 1 > (setq foo 4) > Error: Segmentation fault > (lisp freezes and you must reboot)
> 1 > (setq foo 4) > 4 > 2 > (+ 5 foo) > 37 > 3 >
> Undefined means, hmm, not defined. Which means it isn't defined what > will happen. Which means don't count on anything.
That "37" line caught my attention real fast. Are there actually ANSI Common Lisp implementations that do that, or are you just making it up to try to impress me as to what *might* happen.
BTW, don't bother answering that question if you don't feel like doing so, because I don't want to be accused of turning this NG into a newbie instruction forum.
No one is twisting anyone's arm here to answer questions, and I for certain do not want advice from those who do not desire to give advice.
Stop whining about how much a pain in the kazoo I am, just shut-up and don't participate in the discussion. That is easy enough for anyone to understand, I hope.
In article <EXzua.5533$sS6.5...@news02.roc.ny.frontiernet.net>, Franz
Kafka < @> wrote: > I think asking him if he'd jump off a bridge with Paul Garham was going a > little too far. He already decided that he's going to write his program--I > think we should help him.
I would like to clear up one point.
I have no intention of turning this NG into a Newbie Education Forum, because I believe one is responsible for one's own education, and should not expect others to spoon-feed him instruction.
If resondents *want* to reply to questions, that is a different matter, and I welcome that approach, obviously.
I warned about abusive people here "turning on anyone" who happens to agree with me. I see it is already happening with Henrik's sarcastic remarks below:
"Henrik Motakef" <henrik.mota...@web.de> wrote in message
In article <m33cjp82ky....@javamonkey.com>, Peter Seibel
<pe...@javamonkey.com> wrote: > You can also buy a PDF of the ANSI spec from INICTS for a mere $18 and > however long it takes to download (it's pretty big.) The license > allows you to make a "copy" for "backup" purposes. Dunno if that > technically includes printing out a hardcopy.
> (Of course this is not the same as the ANSI spec but it's a good start > and you'll most likely learn something while you do that. I'm going to > do it this weekend... :)
Lemme know how you make out, I already have CLtL2 so your approach should save me some bucks.
In article <costanza-89110C.23573008052...@news.netcologne.de>, Pascal
Costanza <costa...@web.de> wrote: > > My Mac, running OS 10.2.4 (so-called "OS X") - froze up when I was > > using the downloadable version. That is the first time in six months > > that OS X froze on anything.
> I am also running OS X and don't have this problem. Just try again.
Thanks, I will pass it off as just a random occurance, and reload the HyperSpec back into the Mac.
If it happens again for some unknown reason, I will get hardcopy.
Mark Conrad <nos...@iam.invalid> writes: > No one here has yet presented a valid case for not using > "undefined behavior".
You yourself have presented the *most* valid argument for not using undefined behavior: It isn't guaranteed to work! This is the very reason you came on to this list. Paul Graham made a slight error in his book and depended upon a common, but technically undefined behavior. You stumbled into a case where it did not work as Paul intended.
> On the contrary, a gentleman who is a better Lisp expert than anyone in > this thread, uses "undefined behavior".
That is a rather ignorant statement. Paul Graham is an intelligent guy, but there are several people who post to this list who were instrumental in the *creation* and *definition* of Common Lisp. If you don't value their opinions, I suggest you correspond directly (and solely) with Paul Graham.
> Paul Graham, being the CL expert that he is, was well aware of using > "undefined-behavior" back in 1994, in his "On Lisp" book.
Paul Graham is an intelligent person, but I hardly expect that he knows the quirks of every Common Lisp system in existence. Virtually *every* Common Lisp system allows you to SETQ an undefined free variable at `top-level', despite the fact that the Common Lisp standard expresses no opinion upon what that might mean. The traditional interpretation is that this will set the value cell of the relevant symbol. CMUCL is exceptional in that it does *not* follow this interpretation by default (you can set a flag to get it to do so). This idiosyncracy has tripped up many Common Lisp programmers. Paul Graham doesn't use CMUCL (see his web page).
