In <33D63BED.3...@capital.net> Sajid Ahmed the Peaceman <peace...@capital.net> writes:
[...]
>> >They would expand them [...functions...] inline like a macro definition.
>> In such a languge it would be inpossable to write recursive code. > You could certainly write recursive code, as long as the >number of times the function calls itself is set at compile time.
In most casers where you use recurstion you don't know how meany times that you repeat.
[...]
>> as the size of the >> exicutables would be so massive as to be useless.
> Most programming code out there (about 96%) is >nonrecursive. You've been programming is lisp too long.
Ok lets immagen a module gets called 10 or 12 times, you have now got a 10 or 12 times module size extra code in your program.
-- Please excuse my spelling as I suffer from agraphia see the url in my header. Never trust a country with more peaple then sheep. Buy easter bilbies. Save the ABC Is $0.08 per day too much to pay? ex-net.scum and proud I'm sorry but I just don't consider 'because its yucky' a convincing argument
> > Can you derive the expected time of shell sort for us? > > (trick question it's very hard ). Shellsort does pretty darn > well > > for quie large sets. The expected time is roughly n^(2/3) with a > > low constant factor.
> Er, I think you mean n^(3/2). (And a good shellsort tends to do a bit > better than that, in practice.)
Whupsie. That was a careless transposition. The point I was trying to make was that such a strong reaction against shellsort wasn't necessarily justified.
I blew the qsort() supplied with my C compiler by giving it a sorted set once. I was really dissapointed! To me, that's much 'flakier' that a sort that may be a bit slower in the average case.
> > I'd certianly consider implementing qsort() as heapsort, for > > example. > > heapsort, at least, has space guarantees, even in simple mode. > > In fact, heapsort is in-place.
> If you implement quicksort properly, and you know that it will > never be given a dataset with more than 2^32 elements, you only > have 64 words of stack overhead. The difference in code size > between one sort function and another is going to be way more > than that.
True. You do get space guarantees if you iterate over the larger half of the partition and only recurse over the smaller half. And you only use 64 words if stack of you maintain the stack yourself ( stack frames have overhead !). I was trying to make a point about the *simple* quicksort, though, but you are certianly correct for the properly optimized and tweaked version. You can get space guarantees, and be 99.99% sure of getting roughly the average time.
> On the other hand, heapsort gives *time* guarantees too. (A really > good quicksort implementation is pretty reliable, too, but you have > to be quite careful in order to get a really good quicksort > implementation.)
>> I think indentation style should be one of them.
> Yes and no. Consensus on such matter is extremely important in an > organization, especially when you are not just producing one=shot > programs, but systems which will have to be maintained for a long time > to come.
I'm afraid I disagree. I haven't worked on any large projects, merely medium ones (20-30 programmers), but I've never found other people's indentation styles to severely hamper my work. In fact, someone's style can be a useful signature to see who wrote what. :)
I hate everyone's indentation style but my own. The problem with a standard is that many if not most people are forced to use a style they don't like and aren't comfortable with. This is like forcing everyone to use the same editor. Is consistency in this area (and I invoke Emerson here) important enough to irritate people? Are there any practical reasons for indentation standards--i.e. situations where productivity may suffer without them, and considering that productivity may also suffer with them?
> To: S-n...@stat.wisc.edu > Subject: Bentley's column > Date: Sun, 26 Jan 1992 15:48:26 -0600 > ---- > In his "Software Exploratorium" column from the February 1992 issue of > Unix Review, Jon Bentley discusses some unusual behaviour of the qsort > algorithm that was discovered because of a bug report about S. It is > an interesting discussion featuring the work of Allan Wilks and Rick > Becker in diagnosing the bug.
Dang it. I wasn't going to do this, but I'm bored.
In article <33D8F4C2.1...@capital.net>, Sajid Ahmed the Peaceman <peace...@capital.net> wrote:
>Marco Antoniotti wrote:
>> Mr. the Peaceman, do you have the slightest idea of what you are >> talking about?
> I know exactly what I'm talking about, thank you.
Well, if you know you're talking nonsense, then why should anyone take you seriously?
>> I still have to see the assembly code for the C tree traversal from >> you. But apart from that, if a function is tail-recursive (assuming >> you grasped the concept by now) what you are usually interested in, is >> that the algorithm is provably terminating (and no! you can't answer >> that question in its full generality). In that case the function runs >> in constant space, since it is translated into a loop (if the compiler >> is smart enough as most Lisp compilers are, contrary to many C/C++ >> ones). If the function is inherently recursive (prove they do not >> exist, if you can), then the limit is the amount of memory of your >> computer or some configuration parameter of the language run time >> environment.
> That's not the point. The point is, why make the functions >tail recursive when simple iteration is good enough? It's a waste >of time.
Whoah! Earth to Peaceman. What do you think people have been talking about for the past few days. You started this off by claiming that:
(Dated 7/17) Sajid Ahmed the Peaceman wrote in <33CE5827.6...@capital.net>:
> Anyway, all lisp programs, as well as the compilers and > interpreters are broken down into assembly level code, which is > iterative. The thing I have a problem with is with people trying > to write programs that are completely recursive, which is what lisp > is about. That is the wrong way to go about it. It's a tremendous > waste.
People have been discussing your first claim, that all assembly level code is "iterative," which you have yet to define in a meaningful way.
If I'm reading you correctly, when you say "That's not the point." up above, you are tacitly admitting defeat on this point, but aren't willing to actually state this, so instead you change the subject over to the second point.
> Just write the iterative code. It's faster and more efficient.
Faster to write? That depends completely on what you're used to. More efficient? No, because tail recursion is *equivalent* to iteration.
If you're arguing that you can write iterative code faster than you can write tail-recursive code, than I'll just have to take you at your word. Just don't think you've shown anything more significant than that.
> That's where my gripe in Lisp comes about. It's a >programming language that compiles code into simpler assembly >language machine code. It's not Mathematics, where the results >of functions are instantaneously there. There is no need to >write tail recursive functions, when simple iterative code will do.
Here we go with that second point, the "I don't like Lisp because my mean ol' Lisp instructor made me write everything recursively" argument. Hello? Have you been listening?
First of all, I'd like to see a single programming langauge that doesn't compile code into "simpler assembly language machine code." That's the whole point of a compiiler. And of course it's not Mathematics, no one claimed it was. Really, where do you get these things?
If you prefer "simple iteration" to tail recursion, you are arguing mere style preferences, because, as many others have pointed out, tail recursion is equivalent to iteration.
In fact, you are arguing trivial style preferences, because in CL you are perfectly free to write your iteration using any of the "do" family of iterative constructs or the "loop" macro.
Satisfied? I didn't think so.
Sigh. I have to admit that was kind of fun; you're almost as bad as the "Relativity is wrong because I don't like it" folks over on sci.physics.
- Johann
P.S. From now on, I'll be good. Really. No more responding to flame bait. I should really find more things to do while my computation is running...
-- Johann A. Hibschman | Grad student in Physics, working in Astronomy. joh...@physics.berkeley.edu | Probing pulsar pair production processes.
dmi...@pavel.physics.sunysb.edu (Dima Zinoviev) writes: > In article <33D65B66.3CB8F...@interdyn.com> Nicholas Arthur Ambrose <ni...@interdyn.com> writes:
> > I thought that Fortran77 didn't use the stack. I believe It also > > doesn't allow recursion without some programming trickery. > > Nick
> No it did not (and still does not :-) Once a friend of mine was given > an assignment to implement a recursive algorithm in Fortran, so he had > to emulate the stack using several arrays (remember -- Fortran does > not have structures, either!)
> Besides the sipmlicity of the implementation, there was one more > reason for not using the stack: the speed. Indeed, when C or Lisp make > a function call, a lot of run-time job is being done on the > stack, while in Fortran, a function call gets translated into a single > 'jump' instruction.
This can't be true in general. Where do the procedure arguments go if you have greater than what can be stored in registers? On the stack right?
| And here we see that you have written very little Lisp recently. | whitespaces (single ones at least) are all-important in Lisp. :)
I do understand your point -- that "f oo" is different than "foo " -- I should have said "variances in non-zero amounts of whitespace are considered irrelevant." But this point is pretty minor, no?
| Yes and no. Consensus on such matter is extremely important in an | organization, especially when you are not just producing one=shot | programs, but systems which will have to be maintained for a long time | to come.
Yes, and no. Having *a* coding standard is a Good Thing, without doubt, because it improves programmer efficiency by some small, but reasonable, amount.
The problem is that standards are almost always embroigled in bitter argument and bickering. If everyone could agree: code however you like, but "checkin" WILL run "cb" (with our company's "official standards module" attached) -- hey, that'd be great, wouldn't it?
I frankly couldn't care THAT much about the particular standard. Even if it offends mine eye, I can cope.
I reject categorically that one coding standard is "intrinsically winning" and that all others are "obviously braindamaged."
In article <86afjb2aap....@g.pet.cam.ac.uk> Gareth McCaughan <gj...@dpmms.cam.ac.uk> writes:
From: Gareth McCaughan <gj...@dpmms.cam.ac.uk> Newsgroups: comp.lang.lisp Date: 25 Jul 1997 02:24:46 +0100 Organization: University of Cambridge, England Lines: 29 NNTP-Posting-Host: g.pet.cam.ac.uk X-Newsreader: Gnus v5.3/Emacs 19.34
David Hanley wrote:
> Can you derive the expected time of shell sort for us? > (trick question it's very hard ). Shellsort does pretty darn well > for quie large sets. The expected time is roughly n^(2/3) with a > low constant factor.
Er, I think you mean n^(3/2). (And a good shellsort tends to do a bit better than that, in practice.)
I do not think this is a good practice. You are advertising a function as using a O(n * lg n) algorithm and then you implement it using a slower one. This is not acceptable.
> I'd certianly consider implementing qsort() as heapsort, for > example. > heapsort, at least, has space guarantees, even in simple mode. > In fact, heapsort is in-place.
If you implement quicksort properly, and you know that it will never be given a dataset with more than 2^32 elements, you only have 64 words of stack overhead. The difference in code size between one sort function and another is going to be way more than that.
On the other hand, heapsort gives *time* guarantees too. (A really good quicksort implementation is pretty reliable, too, but you have to be quite careful in order to get a really good quicksort implementation.)
Heapsort is a Theta(n * lg n) algorithm and as such is guaranteed to achieve that performance. However, I would object calling the library function 'qsort'.
-- Marco Antoniotti =========================================================================== === California Path Program - UC Berkeley Richmond Field Station tel. +1 - 510 - 231 9472
In article <sxlu3hkm8z5....@yakko.zso.dec.com>, pe...@yakko.zso.dec.com (Reginald S. Perry) wrote:
> 2) define recursion
From the Maclisp manual:
"Recursion. See recursion."
"Iteration: go to 'Iteration'" :) -- Marco Antoniotti =========================================================================== === California Path Program - UC Berkeley Richmond Field Station tel. +1 - 510 - 231 9472
One of my least favorite programmer arguments concerns which indenting style is "best." For some reason, these usually smart people seem to explode violently when presented with code that doesn't meet their personal indenting style.
I find myself objecting to "inconsistent style". I personally follow the GNU Coding standards because are reasonable and because they are well supported by Emacs.
This usually results in someone in the org mandating a particular style, which produces months of endless bickering, and eventually produces some kind of compromise standard that is both neither fish nor foul and resoundingly ignored.
I have been activly campaigning in my group to enforce the GNU Coding standards. This has led to some bickering, but it is a necessary evil (again, not because the GNU coding standards are bad, but just because they are a "coding standard").
Luckily, many programmers eventually realize that there is a pretty-print program ("cb" for the unix heads), and it can be set to produce the exact style of indenting that is preferred.
Emacs is the program that should be used to do the indentation in the first place :)
What makes this my least favorite is that the argument itself is pointless -- no amount of moving around the brackets is going to change the resulting machine code. (And if it does, you should shoot your compiler vendor, because one of the few STANDARDS of C or Lisp is that whitespace is irrelevant.)
And here we see that you have written very little Lisp recently. whitespaces (single ones at least) are all-important in Lisp. :)
What makes the argument especially pointless is the fact that the need to perform a particular indentation has vanished over the years, because C code editors are finally starting to catch up to Lisp in functionality.
Emacs has had C and C++ modes (written in Emacs Lisp - of course) for at least a decade.
...
Remember what the philosophers said: "We demand rigidly defined areas of doubt and uncertainty." I think indentation style should be one of them.
Yes and no. Consensus on such matter is extremely important in an organization, especially when you are not just producing one=shot programs, but systems which will have to be maintained for a long time to come.
Cheers -- Marco Antoniotti =========================================================================== === California Path Program - UC Berkeley Richmond Field Station tel. +1 - 510 - 231 9472
> > Can you derive the expected time of shell sort for us? > > (trick question it's very hard ). Shellsort does pretty darn > well > > for quie large sets. The expected time is roughly n^(2/3) with a
> > low constant factor.
> Er, I think you mean n^(3/2). (And a good shellsort tends to do a > bit > better than that, in practice.)
> I do not think this is a good practice. You are advertising a > function as using a O(n * lg n) algorithm and then you implement it > using a slower one. This is not acceptable.
Really? Does it guarantee n lg n in the C standard? I don't recall many specification converning time taken in the C standard.
In any case, the crossover between quicksort & shellsort is high enough so that I doubt you'd ever notice the difference. Excepting that you wouldn't be able to break it by giving it a sorted set. :)
> Heapsort is a Theta(n * lg n) algorithm and as such is guaranteed to > achieve that performance. However, I would object calling the library
> function 'qsort'.
Why? I don't recall the algorithm for qsort being specified. Though I have had t write my own sort in C when the built-in one was insufficent. I've never had to do that in common lisp, though. (sort ... ) is pretty powerful, and you get stable-sort as well.
> Mr. the Peaceman, do you have the slightest idea of what you are > talking about?
I know exactly what I'm talking about, thank you.
> I still have to see the assembly code for the C tree traversal from > you. But apart from that, if a function is tail-recursive (assuming > you grasped the concept by now) what you are usually interested in, is > that the algorithm is provably terminating (and no! you can't answer > that question in its full generality). In that case the function runs > in constant space, since it is translated into a loop (if the compiler > is smart enough as most Lisp compilers are, contrary to many C/C++ > ones). If the function is inherently recursive (prove they do not > exist, if you can), then the limit is the amount of memory of your > computer or some configuration parameter of the language run time > environment.
That's not the point. The point is, why make the functions tail recursive when simple iteration is good enough? It's a waste of time. Just write the iterative code. It's faster and more efficient.
That's where my gripe in Lisp comes about. It's a programming language that compiles code into simpler assembly language machine code. It's not Mathematics, where the results of functions are instantaneously there. There is no need to write tail recursive functions, when simple iterative code will do.
> Sajid Ahmed the Peaceman <peace...@capital.net> writes:
> Well this is interesting. How in the world is a move iterative? How is > iterative defined in your world?
> If you want to convince me, you will have to:
> 1) define iteration
> 2) define recursion
> 3) define your assembly pseudo-language subset. this subset has to be > rich enough to describe computations that can be done today on modern > machines.
> 4) define the iterative operation in this language according to your > definition of iterative.
> 5) define the recursive operation in this language according to your > definition of recursive.
> 6) Show how the operations in 5) are equivalent to the operations in 4)
> 7) show that for every operation one can describe in your language, > they all map in to some equivalent of 4)
> Do this, and I will be convinced. I would advise you think carefully > before you start.
> -Reggie
Look, I'm not going to get into a debate
about whether assembly language is iterative or recursive.
The main point I had was about Lisp code, and the postgrad
curriculum in comp sci. I can admit that I was wrong in the
semantics of the language, but I'm not going to change my
views on the way computer science is taught in the post graduate
level. It's computer science, based on computer processors.
It's not mathematics. It is a function on a computer,translated into
lower level assembly language code run one instruction at a time, not a
function in an abstract mathematical world.
You may think I have a problem with mathematics. I don't, as long as there is practical applications in the real physical world. The problem with these abstract mathematical functions, translated into lisp, is that in most instances they don't have any practical use. It's mathematics just for the sake of mathematics. That is a complete waste of time.
> Sajid Ahmed the Peaceman <peace...@capital.net> writes:
> > Igor, most people in the LISP newsgroup can't read your > message > > (which is MIME encoded). They probably use the EMACS Gnus > newsreader, > > which is a good newsreader, but doesn't support MIME encoded > messages.
> > Peaceman
> It does.
Long live EMACS! If your EMACS doesn't do something, just download the latest version. Any new thing that comes around, you can bet that someone, somewhere is writing an e-lisp extension for EMACS.
EMACS - it's not just a program, it's a lifestyle!
* Fred Haineux | Luckily, many programmers eventually realize that there is a pretty-print | program ("cb" for the unix heads), and it can be set to produce the exact | style of indenting that is preferred.
* Walt Howard | You can't do this in a large project. The reason is, you check this code | in. Often it becomes necessary to "diff" two versions to see "what | change made it break". If someone reformatted the whole thing and | checked it in, its impossible to tell what REAL changes were made between | those two versions.
it occurred to me that the problem is that "diff" is run on the text representation of the code. had it been possible "diff" the _code_, each programmer could check his code in and out in his own textual style.
#\Erik -- Thomas J. Watson, founder of IBM: "man shall think. machines shall work." William H. Gates, III, Microsoft: "man shall work. machines shall not."
> > I do not think this is a good practice. You are advertising a > > function as using a O(n * lg n) algorithm and then you implement it > > using a slower one. This is not acceptable.
> Really? Does it guarantee n lg n in the C standard? I don't > recall many specification converning time taken in the C > standard.
As I'm sure you both know, the C standard doesn't require that |qsort()| be a quicksort. On the other hand, the name is, ah, suggestive.
> In any case, the crossover between quicksort & shellsort > is high enough so that I doubt you'd ever notice the difference. > Excepting that you wouldn't be able to break it by giving > it a sorted set. :)
Sorting an array of 10000 integers on one platform I tried it on, a good-ish quicksort was a factor of 2 better than the best shellsort I found. I would expect (but don't have the figures to hand right now) that using generic routines rather than specialised-to-integer ones would show up the difference more rather than less.
And a good quicksort -- even a barely tolerable one -- will do just fine on a sorted set. There are other kinds of input that do a better job of showing up the inadequacies of some common quicksort implementations.
-- Gareth McCaughan Dept. of Pure Mathematics & Mathematical Statistics, gj...@dpmms.cam.ac.uk Cambridge University, England.
My body fell on Sajid Ahmed the Peaceman like a dead horse, who then wheezed these wise words:
> I know exactly what I'm talking about, thank you.
You don't give that impression. Just the opposite, in fact.
> That's not the point. The point is, why make the functions > tail recursive when simple iteration is good enough? It's a waste > of time. > Just write the iterative code. It's faster and more efficient.
Is it? I've not seen any evidence for that claim. Are you perhaps using an example with a poor implementation of Lisp, or even a compiler for another language that doesn't support resursion well?
You might as well "prove" that the Earth is flat, by only looking at a small piece of road that is flat. More realistic examples can also be found.
> That's where my gripe in Lisp comes about. It's a > programming language that compiles code into simpler assembly > language machine code. It's not Mathematics, where the results > of functions are instantaneously there. There is no need to > write tail recursive functions, when simple iterative code will do.
Why use iteration when simple resursion will do? If you want to argue that programming at a lower level is always best, then you should be using assembly language for everything. Is this in fact what you do?
If a programmer choses a particular language, their reasons for doing so need not depend on things like Mathematics. Recursion may be only of many possible reasons for making a choice.
Note that Lisp doesn't depend on recursion. _You_ may think it does, but you insist on demonstration your ignorance of Lisp. I strongly recommend that you go away and read a few of the Lisp tutorials in the Lisp FAQ (you did read the FAQ, didn't you?), and only then should you try to tell people what Lisp can or cannot do.
Assertions based on ignorance can be called mistruths. A less generous way of describing them would be as lies. Yes, I'm calling you a liar. -- <URL:http://www.wildcard.demon.co.uk/> You can never browse enough "My body falls on you like a dead horse" -- Portait Chinois Please note: my email address is gubbish
My body fell on Johann Hibschman like a dead horse, who then wheezed these wise words:
> If you prefer "simple iteration" to tail recursion, you are arguing > mere style preferences, because, as many others have pointed out, > tail recursion is equivalent to iteration.
Alas, some peopl edon't know how little they know. I see this happen in the context of compiler theory all the time. To be fair, most people don't have the time to study compilers. However, when they claim to know all about compilers, in spite of their ignorance, I find it harder to forgive them.
Sajid Ahmed the Peaceman should by now be just starting to realise the true depth of his ignorance in this area. Strangely, his posts seem not to reflect this. I'm not sure what to conclude from this. It would be tempting to just write him off as an idiot, but I've seen enough clueless C++ programmers on UseNet behave differently, when pointing in the right direction, to suspect that Sajid Ahmed the Peaceman's motives are not based on a desire for enlightenment. Instead, I wonder if he's perhaps wishing to spread his ignorance?
He's certainly spreading his clueless memes to one or two newsgroups. Fortunately, anyone reading this can check the facts for themselves. A good place to start is with the Lisp FAQ: <URL:http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai- repository/ai/html/faqs/lang/lisp/top.html> -- <URL:http://www.wildcard.demon.co.uk/> You can never browse enough "My body falls on you like a dead horse" -- Portait Chinois Please note: my email address is gubbish
In article <wkk9ikfcp3.fsf...@cam.org>, Vassili Bykov <vby...@cam.org> wrote:
| It is not fair to say so. Their goal was not writing Infocom-style | games without having to learn Lisp. The goal was writing | Infocom-style games, period. You can't get your hands on the | development system Infocom used (ZIL--"Zork Implementation | Language"--a stripped-down MDL): it ran on DECsystem-20s and, even if | anything remains of it now, is now a property of Activision. So, | learning Lisp, MDL, or ZIL (most unlikely, "a stripped-down MDL" is as | much as you can find out about it now) would not help the tiniest bit.
Although I wouldn't mind seeing a LISP-like language compiler to the Zmachine image format. When I worked on JZIP, my freeware infocom interpreter for UNIX & DOS, (shameless plug: http://ftp.gmd.de/if-archive/infocom/interpreters/zip/jzip201g.zip) I was a little dissappointed that there wasn't. But then again, I haven't gotten off my butt and done it... However, the best spot to start is probably the MDL language docs which you can order from MIT even still. A recent email of mine discovered that the papers were written by the original implementors, too. Here's the info:
( NOTE: Galley wrote The Witness and Seastalker; Lebling cowrote Zork I, II III, and Enchanter, coauthored the original mainframe Zork, Wrote Starcross, Suspect, Spellbreaker, and The Lurking Horror on his own.)
----- included email from docs@MIT -----
From plr...@MIT.EDU Wed May 14 14:22:09 1997 Date: Wed, 14 May 1997 16:22:38 -0400 To: jhol...@frii.com (John Holder) From: trish reid <plr...@MIT.EDU> Subject: Re: LCS papers Cc: d...@MIT.EDU
AUTHOR :Galley, Stuart Wilbur. TITLE :MDL primer and manual : for versions 54 and 104 / S. W. Galley and Greg Pfister. LANGUAGE :ENGLISH PUBLISHED :Cambridge : Laboratory for Computer Science, Massachusetts Institute of Technology, 1977. PHYSICAL DESC :270 p. ; 28 cm. NOTES :Title from cover. Includes index. FUNDING INFO :Office of Naval Research contract N00014-75-C-0661 BIBLIOGRAPHY :Bibliography: p. 260. OTHER AUTHOR :Pfister, Greg.
AUTHOR :Galley, S. W. TITLE :The MDL programming language / S.W. Galley and Greg Pfister. LANGUAGE :ENGLISH PUBLISHED :Cambridge, Mass. : Laboratory for Computer Science, Massachusetts Institute of Technology, c1979. PHYSICAL DESC :276 p. : ill. ; 28 cm. SERIES :MIT/LCS/TR; 293 FUNDING INFO :Supported by the Advanced Research Projects Agency of the Dept. of Defense. N00014-75-C-0661 BIBLIOGRAPHY :Includes bibliographical references. OTHER AUTHOR :Pfister, Gregory F. OTHER AUTHOR :Massachusetts Institute of Technology. Laboratory for Computer Science. OTHER TITLE :Programming language, The MDL.
AUTHOR :Lebling, P. David. TITLE :The MDL programming environment / P. David Lebling. LANGUAGE :ENGLISH PUBLISHED :Cambridge, Mass. : Laboratory for Computer Science, Massachusetts Institute of Technology, 1980. PHYSICAL DESC :iv, 137 p. ; 28 cm. SERIES :MIT/LCS/TR; 294 BIBLIOGRAPHY :Includes bibliographical references and index. OTHER AUTHOR :Massachusetts Institute of Technology. Laboratory for Computer Science. OTHER TITLE :Programming environment, The MDL.
Dear John,
These documents are available for $24 each, including airmail shipment. The first title on your list did not show up on our database, I have given the cite of the closest title. If you would like to purchase a copy, please reply with your VISA, MasterCard or American Express number with expiration date and name as it appears on the card. Or, if you prefer, you may fax that information to us at 617-253-1690. I have included ordering and price information at the end of this message.
Journal Article / $12 (price per article up to 30 pages; overage add $.25/page) RUSH SERVICE: ***Note: Does not include transmission charges*** SAME DAY: $10.00 extra Requests rec'd by 12:00pm Eastern time: Out by 6:00 Same day NEXT DAY: $5.00 extra
MIT Thesis Hardcopy / $51 Microfiche/Microfilm (please specify) / $36 Abstract only / $12
MIT Technical Report/Working Paper $12 / $17 / $24 each (1-30 pages / 31-100 pages / 101-400 pages / 401+ add $.25/page)
MIT Press Out-of-Print Books $51 up to 400 pages Add $.25/pg 401+
ALL PRICES INCLUDE AIRMAIL POSTAGE
DELIVERY OPTIONS 1st Class/Airmail (included in ALL prices) Ariel Electronic Document Transmission System (no additional charge) Fax ($8.00 first 30 pages, add $.50/page overage) Federal Express Overnight Delivery (must supply your own FedEx account number) DHL Express Courier ($25.00 for first 5 items)
PAYMENT OPTIONS Invoice (domestic institutions only, not individuals) Credit card (Visa,Mastercard,American Exp.) -must include card #, exp. date & name as it appears on card Prepayment check -must be in U.S. funds & drawn on U.S. bank; check payable to MIT
>I am studying LISP languages and their variants, and would like to >know how much it would cost (and if it is possible) to order the following >three M.I.T. Publications:
>Dornbrook, M.; Blank, M.: The MDL Programming Language Primer, M.I.T. > Computer Science Lab., MIT/LCS, Cambridge, Mass., 1980
In <sxlsox2n96p....@yakko.zso.dec.com>, pe...@yakko.zso.dec.com (Reginald S. Perry) writes:
> ... >> No it did not (and still does not :-) Once a friend of mine was given >> an assignment to implement a recursive algorithm in Fortran, so he had >> to emulate the stack using several arrays (remember -- Fortran does >> not have structures, either!)
This is an implementation decision. There is no problem allocating local variables on the stack as long as they need not preserve their values between invocations of a function
>> Besides the sipmlicity of the implementation, there was one more >> reason for not using the stack: the speed. Indeed, when C or Lisp make
Depends on the way addressing works on the target hardware. There are quite a few machines around where a stack would actually be faster than static storage.
>> a function call, a lot of run-time job is being done on the >> stack, while in Fortran, a function call gets translated into a single >> 'jump' instruction.
>This can't be true in general. Where do the procedure arguments go if >you have greater than what can be stored in registers? On the stack >right?
You can assign static storage for the function parameters and the caller copies them there (Not that I would recommend it, but it is possible)
In <33D8F4C2.1...@capital.net>, Sajid Ahmed the Peaceman <peace...@capital.net> writes:
> ... > That's not the point. The point is, why make the functions >tail recursive when simple iteration is good enough? It's a waste >of time. > Just write the iterative code. It's faster and more efficient.
> That's where my gripe in Lisp comes about. It's a >programming language that compiles code into simpler assembly >language machine code. It's not Mathematics, where the results >of functions are instantaneously there. There is no need to >write tail recursive functions, when simple iterative code will do.
In case you didn't get it yet, the machine code for iteration and tail recursion are indistinguishable.
> My body fell on Sajid Ahmed the Peaceman like a dead horse, > who then wheezed these wise words:
Sajid Ahmed the Peaceman then threw the dead horse off of himself, and went on with his business.
> > I know exactly what I'm talking about, thank you.
> You don't give that impression. Just the opposite, in fact.
Sorry to burst your bubble. I'm not trying to impress you or anybody else.
> > That's not the point. The point is, why make the functions > > tail recursive when simple iteration is good enough? It's a waste > > of time. > > Just write the iterative code. It's faster and more efficient.
> Is it? I've not seen any evidence for that claim. Are you perhaps > using an example with a poor implementation of Lisp, or even a > compiler for another language that doesn't support resursion well?
Using recursive functions on a computer involves manipulating a stack. Using iterative statements does not. QED.
> You might as well "prove" that the Earth is flat, by only looking at a > small piece of road that is flat.
What's that have to do with anything?
Like I said in the post that your replying to, my gripe is towards programmers (Lisp as well as others) living in their own fantasy abstract mathematical world. It's time to accept reality.
Martin Rodgers arranged ascii chars in this pattern...
>Is it really CLOS that they object to? How interested are they in the >programming details, and why?
Actually, at this point, I don't accept clients who want code written in C++ unless they wish to pay a significant premium for it. Unfortunately, I often end up programming in C or C++ because I believe it is in my clients' best interest. The main engineering motivations here are
1. compatability with windows, which is much easier to achieve with tools from MS. Try writing a windows NT device driver in anything but C++.
2. standalone executables. Again, try writing a windows NT device driver in anything but C++.
3. code that can be extended and maintained by one of the million of resonably competent C or C++ programmers out there. This is actually far less important than it sounds. If there were a really good lisp/c interface then any resonably competent programmer should be able to extend any program using a language of his or her own choice (even Visual Basic).
>"Visual CLOS" sounds very tasty. Where can I buy it? ;) >--
If LISPMachine were still around, they'd sell it to you now (and develop it later!). Give me some time. If I had a couple of megabucks (or even megapounds) I'd have some people writing it as we speak. Unfortunately, I don't think a good Visual CLOS is a one-person affair.
My body fell on Sajid Ahmed the Peaceman like a dead horse, who then wheezed these wise words:
> Sorry to burst your bubble. I'm not trying to impress > you or anybody else.
I didn't think you were trying to impress anyone. Oh no.
> Using recursive functions on a computer involves manipulating > a stack. Using iterative statements does not. QED.
Really? How is it, then, that I can write tail recursive functions in C, and when compiled with a C compiler that optimises tail recursion, the resulting code reuses the activation record during a tail call?
You can also write recursive decent parsers in a wide variety of languages, including C. I first did this more than 10 years ago. Have you tried it yet?
> > You might as well "prove" that the Earth is flat, by only looking at a > > small piece of road that is flat.
> What's that have to do with anything?
See my above points about recursion.
> Like I said in the post that your replying to, my gripe > is towards programmers (Lisp as well as others) living in their > own fantasy abstract mathematical world. It's time to accept > reality.
So recursive decent parsers have no practical value? Could it be that they use abstract mathematical ideas that you object to? Say bye bye to all the world's compilers. Sajid Ahmed the Peaceman has declared them to be unnecessary applications of abstract mathematics.
You can program in all kinds of languages without going into any more abstract mathematics than, say, ANSI C. Perhaps you just had a poor teacher who gave you the impression that Lisp is way too complex for you? If so, then find a better teacher. The Lisp FAQ can recommend a number of excellent books. A deeper understanding can come later.
Don't blame the language, friend. Blame your education. Some people get put off algebra for the same reasons. It's not too late to correct the damage. Stop attacking something because you don't understand it.
Someone who with your lack of understand is either ignorant or stupid. Now, ignorance can be cured with education. Are you willing to learn? -- <URL:http://www.wildcard.demon.co.uk/> You can never browse enough "My body falls on you like a dead horse" -- Portait Chinois Please note: my email address is gubbish
