Paul Foley <mycr...@actrix.gen.nz> writes: > When thinking of conses as conses I prefer CAR and CDR to FIRST and > REST , but when thinking of them as a list, I usually prefer > FIRST/SECOND/REST/etc. [Though I sometimes use CAR/CDR out of habit;
But I love the fact that lists are just conses of conses, and I love expressing them that way. One of the Lisp books I read had a section on "why Lisp doesn't have pointers", but I realized they were wrong: _everything_ is a pointer. Then I was Enlightened.
What's that quote? "I like Lisp because you can feel the bits between your toes."?
> and I use CADR and CADAR but rarely other variants]
I used CAR through CADDDR today.
I also discovered the ~R directive for FORMAT. That was fun.
-- vsync http://quadium.net/ - last updated Fri Jun 23 23:28:05 MDT 2000 (cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner (cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil)))
* Johan Kullstam <kulls...@ne.mediaone.net> | except for CLOS which affixes -p no matter what.
Um, where does CLOS do that?
| which is your (and probably the majority's) opinion. it's also | somewhat of what you are used to. changes are usually unwelcome. | gratuitous change more so.
Well, I have made it the biggest issue of my life and carreer to be able to sustain dramatic changes with a minimum of personal cost. This has certain costs of its own, which would be unwelcome to people who prefer _most_ things to be practically static in their life, but staying on top requires so much adaptability to change that I consider "changes are usually unwelcome" to be a dumb thing to say in our time. 10 years ago, it would make much more sense as a general statement for our part of the culture, but the world has, well, changed a lot in 10 years, and sticking to old stuff is the hallmark of unemployed or retired IT specialists. The morale of this gripe is simply: Don't assume that people are so unable to deal with change that they will use it as an argument against anything. Chances are that anyone who makes a reasonably good living in information technology these days have to deal with a rate of change that would probably drive someone literally insane in the 70's.
Incidentally, I recommend Alvin Toffler: Future Shock to anyone who think adapting to change is too expensive.
Oh, and as an irrelevant side-note: The the kinds of things that _don't_ change bug me the most. Stupidity, for instance.
#:Erik -- If this is not what you expected, please alter your expectations.
* Johan Kullstam <kulls...@ne.mediaone.net> | i think i'm intentionally not caring what the "!" convention means in | scheme or dylan. some lisp operations end in an "f", e.g., SETF, INCF. | one could have spelled it SET! and INC! respectively. it seems most | people here prefer the traditional way. so be it.
No. They would be probably spelled SETF! and INCF!, since the F has nothing at all to do with mutating anything, it has to do with what is being accessed (and mutated). Please understand this and quit that annoying noise about the suffix F. It's dead wrong. Repeating it so annoyingly often means you don't listen, and that very likely means your other notions are not based on listening, either, which is a very nice way of saying that they are your own inventions.
#:Erik -- If this is not what you expected, please alter your expectations.
>> Argh! I am the only one that's bothered by this godawful Schemish use >> of `?' in symbols for "predicate" functions/values? > there's no accounting for taste. i happen to like ? and ! over the > more traditional p and f. just because this notation comes from > scheme doesn't necessarily make it bad. it's only a style convention.
I didn't say it was bad _because_ it comes from Scheme. I guess the main reason I dislike it is that I think verbally, and automatically read the punctuation marks as changes in "intonation" (if I can use that word of a thought), and it's really jarring to have it come in the programming-language equivalent? of the middle! of a sentence.
[I'm not aware of any tradition of using "f" in Lisp where Scheme uses "!". SETF is a fairly recent addition to Lisp, and SETQ was originally a minor variation on SET.]
-- Nomina stultorum in parietibus et portis semper videmus. -- Cicero
Centuries ago, Nostradamus foresaw a time when Erik Naggum would say:
>* Johan Kullstam <kulls...@ne.mediaone.net> >| i am not saying use scheme's set!, i am saying we could just as well >| have spelled common-lisp "setf" as "set!" [2].
> No, we couldn't. ! is overcute, childish, silly, even ridiculous, > the sort of immature reminders that C programmers who build complex > prefix systems ["Hungarian" noation] in their variable names use > because they lose track of type information. ? at least has _some_ > merit, but its association with ! is not to its credit.
Worse still, it's more likely due, not to Scheme, but rather to _Forth_.
: add2! dup @ 2 + ! ; -- cbbro...@ntlug.org - <http://www.ntlug.org/~cbbrowne/lsf.html> Rules of the Evil Overlord #77. "If I have a fit of temporary insanity and decide to give the hero the chance to reject a job as my trusted lieutentant, I will retain enough sanity to wait until my current trusted lieutenant is out of earshot before making the offer." <http://www.eviloverlord.com/>
> I don't know, but I despise the use of "FIRST" and "SECOND" in Winston > and Horn. I _like_ using CAR, CDR, and the like, because it actually > shows the operations taking place, and it's intuitive that CADDR takes > a little more time than CAR. Whenever anything is made "friendly", > there's lossage involved, and painful ignorance on the way.
When thinking of conses as conses I prefer CAR and CDR to FIRST and REST , but when thinking of them as a list, I usually prefer FIRST/SECOND/REST/etc. [Though I sometimes use CAR/CDR out of habit; and I use CADR and CADAR but rarely other variants]
I don't think of FIRST and REST as replacements for CAR and CDR.
-- Nomina stultorum in parietibus et portis semper videmus. -- Cicero
Tim Bradshaw <t...@cley.com> writes: > * Johan Kullstam wrote: > > except for CLOS which affixes -p no matter what. i do think the CLOS > > behavior is correct. having defclass parse the symbol name string and > > use -p or p depending on presence of - or not seems to be a bit more > > fanciness than is warranted.
> I think you mean DEFSTRUCT, not DEFCLASS (which doesn't define a > predicate)
yes. thanks.
-- J o h a n K u l l s t a m [kulls...@ne.mediaone.net] Don't Fear the Penguin!
> > I think you're misunderstanding the '!' convention as used in Scheme > > and Dylan. I believe that the bang suffix is used to denote mutators. > > CL's "nappend" would be "append!"; "nreverse" would be "reverse!"; > > "sort" would be "sort!", and so forth.
> exactly: FORTH. Did this '!'-convention perhaps come from Forth, where it's > usually pronounced as 'store' (as in: "42 the_answer !", which puts 42 into > the variable the_answer)? Or is it is more likely to have come from mutators > being indicative of imperative (as in "Do this! Do that!") programming?
I don't know. I've wondered about a possible Forth connection, too. I've always had a good feeling about Forth since it was the second computer language I learned and found that it was so far superior to the first (Basic on a Radio Shack TRS-80 Model I) that I stuck with it for quite a while. It's too minimalist, though, and too fragmented, but it was _fun_ to work with. I've always hated C and C++, could tolerate Ada95, but didn't rediscover the _joy_ of programming until I encountered Lisp last year and took the time to really look into it.
> (I must say though, that NREVERSE doesn't receive much of an aesthetics or > clarity price either)
No, it certainly doesn't. One thing I really like about Scheme is that it's very clean and consistent (what there is of it; although I'm not too sure about continuations being all that clean). Having strong opinions on whether set! or setf is preferable strikes me as akin to having strong opinions about whether sandwiches should be sliced vertically or diagonally -- i.e., some people probably need more fiber in their diet. 'setf' makes as little sense to me as 'set!' -- so it's short for 'set field', so what? What _else_ could it possibly set other than various words meaning the same thing? Why couldn't it have just been called 'set'?
Either way, I find Scheme's consistency pleasing (as far as it goes) and Common Lisp's many idiosyncracies in this regard rather dopey -- I realize there are historical reasons for all of them, but I've never been one to revere tradition simply for tradition's sake. Of course, I also think the English alphabet needs to be somewhat enlarged and made phonetic -- 'cat' _should_ be spelled 'kat' and the letter 'c' used to represent just the 'ch' sound instead of also masquerading as an 's' sometimes and a 'k' at others.
Common Lisp is a lot more usable than Scheme (though most Schemes have a lot of (mutually incompatible) extensions that partially make up for the slim standard), but I'd like to see a "grown-up" Scheme -- a standard that embraces the functionality of Common Lisp while remaining as clean and consistent as possible. In theory, Scheme is clean and consistent now, but in practice it's not because of all the extensive, incompatible add-ons each version finds necessary to put in. That's why I'm returning to Common Lisp after an extended detour to learn Scheme -- Scheme's not as practical. One might hope that will change, but at the rate the Scheme standard grows, it will reach Common Lisp's functionality long after I'm dead.
Johan Kullstam wrote: >Paul Foley <mycr...@actrix.gen.nz> writes: >> On 28 Jun 2000 10:43:21 +0200, Friedrich Dominicus wrote: >> > CL-USER 9 : 1 > (multiple-value-bind (item present?)
>> Argh! I am the only one that's bothered by this godawful Schemish use >> of `?' in symbols for "predicate" functions/values?
>there's no accounting for taste. i happen to like ? and ! over the >more traditional p and f. just because this notation comes from >scheme doesn't necessarily make it bad. it's only a style convention.
>i do use p and f because it's hard to fight the tide of tradition. >macros for CLOS, for example, automatically define a -p instead of a ? >suffix. lisp, being an old language, has many of these minor >traditionals which could have been better but live on for >historical reasons.
>you may actually be the only one this bothered.
I personally prefer -bool over ? or -p suffixes where is enough room. here as once used argument there is enough room, inside loops or nested calls I would favor a short p?
-p is reserved for a function, not the variable, ? is fine in a variable name, but I prefer more readable names, so dummies (coming from pascal/C/java, ...) can also understand it without the bruden to be forced to think in cryptic language specific pre-/suffix conventions as with scheme, lisp, ms-hungarian and such. -- Reini Urban http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
This is more useful of course when you want to call some other constructor, like #'cons, or some BOA structure constructor, etc.
Regs, Pierre.
-- Pierre Mai <p...@acm.org> PGP and GPG keys at your nearest Keyserver "One smaller motivation which, in part, stems from altruism is Microsoft- bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
> > Argh! I am the only one that's bothered by this godawful Schemish use > > of `?' in symbols for "predicate" functions/values?
Actually, I prefer it. In effect, they're asking a true/false question and the '?' makes sense in that regard. More sense than 'p' or sometimes '-p' stuck on the end, at least to me. I never had any problem with 'set!' instead of 'setf', either, perhaps because it's similar to Forth's '!' (store) operator and I used Forth for a number of years. At least Scheme uses '!' consistently, identifying all destructive functions similarly. I honestly don't see how prepending an 'n' to a function (_especially_ with 'nconc' as the destructive version of 'append' -- where's the logic there?) is any better. I'm considering renaming a number of CL functions and macros for use on my own system, perhaps with a translator to restore them to their original form for any code I might put in a public forum. I suppose there's some dangers in that, though -- I've used HP (RPN) calculators for so long that now I can barely use a TI or Casio without making so many mistakes I'd be better off using pencil and paper.
> I don't know, but I despise the use of "FIRST" and "SECOND" in Winston > and Horn. I _like_ using CAR, CDR, and the like, because it actually > shows the operations taking place,
I don't see this, unless you are using the IBM mainframe on which Lisp was first developed -- and even then, the abbreviations for 'Contents of Address Register' and 'Contents of Data Register' aren't very meaningful...
I've always thought 'head' and 'tail' would've made a lot more sense even 40+ years ago, and possibly 'htail', 'httail', etc. as extensions. For some things, though, like getting the nth element of a list, other words are a _lot_ clearer, though I name them 'first-of', 'third-of', etc.
> and it's intuitive that CADDR takes > a little more time than CAR. Whenever anything is made "friendly", > there's lossage involved, and painful ignorance on the way.
I'm not a fan of what's usually passed off as "friendly," what you state is usually the reality. I _am_ a big fan of "clearer", though, and that's truly friendly, but only as a consequence.
"Larry Elmore" <ljelm...@prodigy.net> writes: > > I don't know, but I despise the use of "FIRST" and "SECOND" in Winston > > and Horn. I _like_ using CAR, CDR, and the like, because it actually > > shows the operations taking place,
> I don't see this, unless you are using the IBM mainframe on which Lisp was > first developed -- and even then, the abbreviations for 'Contents of Address > Register' and 'Contents of Data Register' aren't very meaningful...
I honestly can't explain it; the names CAR and CDR just made instant sense to me, and have stuck with me as The Logical Way To Do Things ever since.
As far as IBM mainframes go, I have never used a mainframe, and the most ancient Lisp architecture I have used is CLISP (plus Emacs, if that counts =). But although the terms themselves may not have been the best choices, using them allows me to _visualize_ the operations in my head. Quite literally. I can see the pointers and the lists and the structures. No other language has let me do that as easily.
Anyway, I find legacy hardware quite easy to understand and in many ways more elegant than today's systems. Just a personal quirk.
> I've always thought 'head' and 'tail' would've made a lot more sense even
Mmmmm... Prolog.
-- vsync http://quadium.net/ - last updated Thu Jun 29 13:01:57 MDT 2000 (cons (cons (car (cons 'c 'r)) (cdr (cons 'a 'o))) ; Orjner (cons (cons (car (cons 'n 'c)) (cdr (cons nil 's))) nil)))
* "Larry Elmore" <ljelm...@prodigy.net> | I don't see this, unless you are using the IBM mainframe on which | Lisp was first developed -- and even then, the abbreviations for | 'Contents of Address Register' and 'Contents of Data Register' | aren't very meaningful...
AFAIK, they were the instructions used to extract halves of a kind of pointer, and it consisted of an address part and a decrement part (not data). A stack that knew its size was easily implemented with this scheme, and it was done just that way on the PDP-10 I grew up on (for all practical purposes) -- both stack and more specialized instructions would add 1 to both halves of the machine word and you could test for overflow at this point if the _negative_ size would overflow into zero. If you read the Lisp 1.5 Programmer's Reference Manual carefully, you'll much intermingled discussions of the special treatment of negative pointer values -- the sized pointer concept was clearly _abused_ by the Lisp implementation on that IBM processor! I found this quite amusing when I read it.
(Argh, this remind me that I pushed a request for an explanation of the power of the PDP-10 macro assembler on my internal stack, and it _doesn't_ signal overflow. Sigh.)
| I've always thought 'head' and 'tail' would've made a lot more sense | even 40+ years ago, and possibly 'htail', 'httail', etc. as | extensions. For some things, though, like getting the nth element of | a list, other words are a _lot_ clearer, though I name them | 'first-of', 'third-of', etc.
Hm? I already pronounce (first foo) as "first of foo".
#:Erik -- If this is not what you expected, please alter your expectations.
In article <3171439197402...@naggum.net>, Erik Naggum <e...@naggum.net> writes:
> * "Larry Elmore" <ljelm...@prodigy.net> >| I don't see this, unless you are using the IBM mainframe on which >| Lisp was first developed -- and even then, the abbreviations for >| 'Contents of Address Register' and 'Contents of Data Register' >| aren't very meaningful...
unless memory deceives me very badly, the d in cdr stands for decrement. given the limited amount of memory those machines had, there usualls was enough space in a word or register to kep two addresse, and manu machines had an optimization feature that let you store a second value in a (n index)register that was added to or subtracted from the other (address) part every time the register got accessed.
In article <395e5...@news.sentex.net>, Hartmann Schaffer wrote: >In article <3171439197402...@naggum.net>, > Erik Naggum <e...@naggum.net> writes: >> * "Larry Elmore" <ljelm...@prodigy.net> >>| I don't see this, unless you are using the IBM mainframe on which >>| Lisp was first developed -- and even then, the abbreviations for >>| 'Contents of Address Register' and 'Contents of Data Register' >>| aren't very meaningful...
>unless memory deceives me very badly, the d in cdr stands for >decrement. given the limited amount of memory those machines had, >there usualls was enough space in a word or register to kep two >addresse, and manu machines had an optimization feature that let you >store a second value in a (n index)register that was added to or >subtracted from the other (address) part every time the register got >accessed.
You're very close to the truth. Larry is a farther away (and his expansions of CAR and CDR get quoted a lot -- or "Contents of Decrement Register" if you're lucky).
The IBM 704 had 36-bit words and 15-bit (!) addresses. Words used as data had four parts: 3-bit tag (or prefix?) field, 15-bit address field, 3-bit prefix (or tag?) field, and 15-bit decrement field. I'm not sure where the prefix and tag fields go in the word.
LISP 1.5 rarely or never uses the prefix and tag fields. CONS cells have 0 in those fields. So that's why you only get CAR and CDR; earlier versions of LISP gave you CPR and CTR (and CWR for the whole word) as well but evidently they were too useless to keep.
Of course LISP does have full words (numbers, names of symbols, machine instructions) in which all the fields are full, but they aren't treated as separate fields so you aren't allowed to get the parts of full words.
The real key to the etymology is that "register" once referred to _all_ memory locations, not just the ones internal to the CPU. If you programmed the machine directly, you might want to refer to the address field of location 12345. This would be the contents of the address field of register 12345, or CAR 12345. LISP added names (symbols) so you didn't have to refer to absolute memory locations, but the usage is almost the same. (CAR FOO) converts FOO to an absolute location and gets you the contents of the address field at that location, or register. The part about index register instructions is true but is a red herring.
> In article <395e5...@news.sentex.net>, Hartmann Schaffer wrote: > >In article <3171439197402...@naggum.net>, > > Erik Naggum <e...@naggum.net> writes: > >> * "Larry Elmore" <ljelm...@prodigy.net> > >>| I don't see this, unless you are using the IBM mainframe on which > >>| Lisp was first developed -- and even then, the abbreviations for > >>| 'Contents of Address Register' and 'Contents of Data Register' > >>| aren't very meaningful...
> >unless memory deceives me very badly, the d in cdr stands for > >decrement. given the limited amount of memory those machines had, > >there usualls was enough space in a word or register to kep two > >addresse, and manu machines had an optimization feature that let you > >store a second value in a (n index)register that was added to or > >subtracted from the other (address) part every time the register got > >accessed.
> You're very close to the truth. Larry is a farther away (and his expansions > of CAR and CDR get quoted a lot -- or "Contents of Decrement Register" if > you're lucky).
> The IBM 704 had 36-bit words and 15-bit (!) addresses. Words used as data > had four parts: 3-bit tag (or prefix?) field, 15-bit address field, 3-bit > prefix (or tag?) field, and 15-bit decrement field. I'm not sure where the > prefix and tag fields go in the word.
> LISP 1.5 rarely or never uses the prefix and tag fields. CONS cells have 0 > in those fields. So that's why you only get CAR and CDR; earlier versions > of LISP gave you CPR and CTR (and CWR for the whole word) as well but > evidently they were too useless to keep.
> Of course LISP does have full words (numbers, names of symbols, machine > instructions) in which all the fields are full, but they aren't treated as > separate fields so you aren't allowed to get the parts of full words.
> The real key to the etymology is that "register" once referred to _all_ > memory locations, not just the ones internal to the CPU. If you programmed > the machine directly, you might want to refer to the address field of > location 12345. This would be the contents of the address field of register > 12345, or CAR 12345. LISP added names (symbols) so you didn't have to refer > to absolute memory locations, but the usage is almost the same. (CAR FOO) > converts FOO to an absolute location and gets you the contents of the > address field at that location, or register. The part about index register > instructions is true but is a red herring.
> -- Derek
Isn't it strange that early machine archtectures still have such an impact on modern programming languages? This is the same as the zero terminated strings in C, but one would not expect this kind of thing in Lisp2!
Erik Naggum <e...@naggum.net> schrieb in im Newsbeitrag: 3171547074485...@naggum.net...
> * "Janos Blazi" <jbl...@vipsurf.de> > | Isn't it strange that early machine archtectures still have such an > | impact on modern programming languages?
> No. Genuinely good ideas don't suddenly turn bad because of the > passage of time.
> | This is the same as the zero terminated strings in C,
> No, it isn't.
Prima facie it seemed to be tha same, but I possibly some deeper analysis may show that you are right.
> | but one would not expect this kind of thing in Lisp2!
> Lisp2?
I saw at the Python home page that they are working on some minor changes and they wanted to call it Python 1.6 after 1.5.2 but now they call it Python 2 as "some companies do not use products the version numbers of which start with a 1". And I feel that such hype, however disgusting, may be helpful.
> Take a look at LDB and DPB some day you're prepared for a shock.
Hahaha! Now I did not want to be reprimanded again so I took a look in the Net and found in google.com that "LDB" stands for "regrettable debugger" and "Long Distance Bacgammon players" and "'Little Drummer Boy' drum loop creation software" on the first page and there are nine other pages to follow.
Janos Blazi wrote: > Hahaha! Now I did not want to be reprimanded again so I took a look > in the > Net and found in google.com that "LDB" stands for "regrettable > debugger" and > "Long Distance Bacgammon players" and "'Little Drummer Boy' drum loop > creation software" on the first page and there are nine other pages > to follow.
* "Janos Blazi" <jbl...@vipsurf.de> | > Take a look at LDB and DPB some day you're prepared for a shock. | | Hahaha! Now I did not want to be reprimanded again so I took a look in the | Net and found in google.com that "LDB" stands for "regrettable debugger" and | "Long Distance Bacgammon players" and "'Little Drummer Boy' drum loop | creation software" on the first page and there are nine other pages to | follow.
Sigh. HINT: Check the HyperSpec. Also the Hacker's Dictionary.
#:Erik -- If this is not what you expected, please alter your expectations.
