> As I understand it, what Matthias Blume is saying is that all objects in > Lisp are, effectively, pointers. And so the pointer is being copied.
I would prefer to say: "most lisp values have reference semantics", and I would prefer to talk about abstract "locations" instead of "pointers" (which people (incorrectly) associate with all kinds of concrete things that do not apply here).
> At the surface level, it is pointless and a distraction to teach it this > way. All objects in Lisp are pointers, yes, but saying so causes people > who know about pointers to expect a certain set of things to be available; > for example, they expect addition on a pointer to mean something different > than it does. They are confused that x+1 does not add one to the pointer > x getting a pointer to the next thing;
Nonsense. There are many languages where there is no addition on pointers and yet they have pointers. Mentioning the word "pointer" does not (or: should not) imply "C pointer".
> C has no equivalent function, > _certainly_ not as an infix operator, that dereferences a pointer, adds > 1, mallocs a new result, and yields a pointer result.
That is completely besides the point. Such a function could easily be defined.
> I don't agree with teaching a language by appeal to datatypes that are > below the level of abstraction that the language was created to indulge.
Right. I would not want to appeal to specific data representations either. Notice that initially I quite carefully avoided the term "pointer" and talked about abstract things like "locations".
> If I wanted to program in C concepts (an assembly language layer with > respect to Lisp), I would be programming in C. I am in Lisp for a > reason, and I will use terms appropriate to Lisp.
As you should. Just make sure that you use terms that actually describe accurately what's going on in Lisp, but don't coin new terms for things for which there are perfectly good language-independent terms available. "Call-by-value" is an example for such a term.
> > ... we're a very old language community that pre-dates those > > things which are asserting a right to dictate terminology...
> but there is a shared terminology in use for a long time, is there > not? what happened to mccarthy's or allen's or stoy's terminology? > not good enough anymore?
I have learned that if the word 'politics' doesn't enter discussions like this, you're either speaking some form of Orwellian newspeak that hides the word, or else you're not seeing the whole game.
I seriously doubt that questions like 'what happened to' will be yielded with answers like 'a technical problem arose'. Usually the answer will be 'a terminological battle arose' and a particular person or their book or their course won. The mistake is to assume, as newly elected Presidents of the US often do, that the mere fact of election to office construes mandate or even approval of all of one's detailed agenda; it just means that the entire package, taken as a whole, was better than another entire package. And so, too, when communities elect a certain book that teaches new terminology, they are often not buying into every detail of that terminology per se, they are simply saying that the overall value of the book is such that going for it is better than not...
And even now, the ironic thing is that Matthias is basically arguing against my terminology not on the basis of "is this a correct and sufficient formalism?" but rather on the basis of "does this fit in with other formalisms already in use politically in some other forum?" ... it's fine for him to do this, but in so doing he makes a de facto acknowledgment that it's political flow, not internal conversational coherence and correctness, that is delivering a particular outcome.
And so while there are a few people in this discussion with an outright confusion about how things work, I think mostly we're all just battling over what "feels better". And I think that's silly, since it's a known thing that different things feel better to different people. And if you acknowledge that, then the question of what the right thing is really comes down to a an issue of statistics. And I don't see anyone make quantitative statistical arguments.
- - - -
Incidentally, I disagree with the point that Erik made that this is all CS101. (I don't know if he really would disagree with my disagreement though. :-) I think the underlying issue here is that some of us might WISH that all people had learned this in CS101, but that there is no such course and really a LOT of people come to the table absent these terms and concepts, certainly absent them with sufficient rigor of capability to be able to manipulate them. Geez, what 101 course leaves much of anyone competent; if they were competent, we'd graduate them and send them out to the field to do work. 101 courses preview concepts and raise basic awareness. And basic awareness is not enough to grasp the subtlety of this discussion; if it were, this discussion would not still be running after this many messages. We'd all just be saying "oh, of course. obviously" and stopping in wild agreement. The fact is that people come to languages with very different backgrounds, and Lisp at least seeks to be a language of the common man, not just of CS elitists--at least, _I_ want that of it. And so I will not put CS formalist terminology in between a potential Lisp convert and their success. The Scheme community seems to not mind doing this, and this is one of many ways I generally prefer myself associated with this political party rather than that one...
Matthias Blume <matth...@shimizu-blume.com> writes: > > You are severely hampered by your higher education.
> You are getting severely rude.
Matthias, I think he didn't say this point to be rude. He said this as a way of making an auxiliary point, which seemed a point of some substance that needs to be said.
Coby didn't say you were uneducated; just the opposite. His statement does not appear to be about _you_, it's about the subjective goodness of the situation in which you find or place yourself.
It is a legitimate and interesting point of contention whether 'formalism' is serving people or confining them, and Coby was (perhaps in an impolitic fashion) trying to touch on this. It's very difficult to enter into a discussion about this without risk of confusion, but it's an interesting area to discuss if we can all retain a bit of detachment here and keep to the issues, perhaps even cutting some people some slack for the fact that English (or any human language) is tough to phrase things in such that all such confusions will be reliably avoided.
You yourself have said some things to me in this thread that struck me as rude. However, I have not called you on it because I don't think your purpose was to be rude. (I guess you're welcome to correct me on this if you intended to insult me and are annoyed you failed. :-)
k...@ma.ccom (Takehiko Abe) writes: > Harbison & Steele states "C provides only call-by-value parameter > passing. This means that the value of the actual parameters are > conceptually copied into a storage area local to the called function." > <Sec 9.5>. This behavior is different from that of Common Lisp.
It's *identical* to Common Lisp. In Common Lisp, the "value" of the "parameter" is a *reference*, and that *reference* is indeed copied into a local storage area.
Nils Goesche <n...@cartan.de> writes: > because not only are people not familiar with those terms, the > theory is also not (yet?) capable of fully describing the > semantics of Lisp or C, anyway, as you well know (EVAL, anyone?).
> Coby didn't say you were uneducated; just the opposite. His statement > does not appear to be about _you_, it's about the subjective goodness > of the situation in which you find or place yourself.
I know what he wrote. He basically harped on the old "ivory tower" thing, with more than just an innuendo that I might have lost touch with reality because of whatever education I might have. I find that rude.
> It is a legitimate and interesting point of contention whether > 'formalism' is serving people or confining them, and Coby was (perhaps > in an impolitic fashion) trying to touch on this. It's very difficult > to enter into a discussion about this without risk of confusion, > but it's an interesting area to discuss if we can all retain a bit of > detachment here and keep to the issues, perhaps even cutting some people > some slack for the fact that English (or any human language) is tough to > phrase things in such that all such confusions will be reliably avoided.
Right. This is precisely why fields such as PL semantics exist: They try to make things as unambiguous and precise as possible, usually by borrowing methods from mathematical logic, domain theory, category theory, etc. (By the way, our discussion here has not even scratched the surface of any of that.) The problem is that many (if not most) people with some programming experience have learned things by remembering a number of more or less (often much less) accurate metaphors. Confusion arises whenever the metaphor gets interpreted too literally.
Example: Someone might explain the concept of a cons cell to a Lisp newbie who has some C background by saying "Think of a little struct with two fields." This is close to the truth, but not close enough. Much closer to the truth would have been to say "Think of a *pointer* to a little struct with two fields." The entire discussion about copying a value vs. not copying a value is precisely due to the confusion arising from this seemingly minor slipup.
> You yourself have said some things to me in this thread that struck me > as rude. However, I have not called you on it because I don't think > your purpose was to be rude. (I guess you're welcome to correct me on > this if you intended to insult me and are annoyed you failed. :-)
I probably know what you mean. Sorry about that. I was just getting a bit grumpy.
> > > C books that explain things correctly exist.
> > Really? Would you be so kind as to cite a few?
> Harbison & Steele.
That's one. You said there were books - plural.
But the real point I was trying to make is that the canonical books -- Stroustrup and K&R -- are not on this list.
> > No need to write a couple of hundred, but it should be a number greater > > than zero if you want to claim that it's not your fault that people don't > > know this stuff. People don't know this stuff because they read > > Stroustrup's book instead of yours, because his exists and yours doesn't.
> I am not in the business of writing C or C++ books. I cannot take the > blame for every ommision and mistake of others just because I have not > filled in the gap or provided the correction. Or are you going to > blame me for world hunger next?
Maybe. Do you have the knowledge and the means to do something about world hunger? If you do and you chose not to do anything then yes, I blame you for world hunger (to the extent that it exists because you chose not to do what you could).
I *do* know that you have the knowledge and the means to write books about C. You've chosen not to. Not only that, but you haven't even provided pointers to the good books you say are already out there. (You've now provided one, but I had to drag that one out of you.)
So yes, you can take the blame for every omission and mistake of others precisely because you have not filled in the gap or provided the correction. If not you, then who?
> > I didn't say it was a problem. I didn't say it wasn't easy. I just said > > it was a substantial amount of work.
> But it isn't.
Yes, it is.
> > You could prove me wrong by posting some code that shows how it's done. > > If it's as dead-easy as you say it shouldn't take you very long.
> Write > struct foo * f (struct bar * x) ... > where you would have written > struct foo f (struct bar x) > Then replace occurences of "x." with "x->".
> (In C++ you don't even have to do the latter, IIRC.)
> This move from struct variables to "pointer to struct" variables must > be applied, mutatis mutandis, to other parts of the program as well. > But doing so is trivial.
Hogwash. It's so non-trivial you had to resort to Latin to even *describe* the process. But even if the *description* of the process is trivial doesn't mean the process itself is trivial. (If you want to claim that the process is trivial then you should post the code that will automatically convert my C code to the new argument passing convention.) And even if the process itself is trivial doesn't mean that the *quantity* of work involved is small. And that's what I'm talking about: a "substantial amount" refers to the quantity of work, not its intellectual difficulty.
But all this is moot because your solution is not even *correct*. It reproduces only one aspect of Lisp's calling semantics (the easy part), and my claim was that reproducing "all aspects of Lisp's argument passing semantics in C++" is a substantial amount of work. That includes things like &rest and &key.
So you are wrong. Top to bottom, end to end, no matter how you slice it, wrong. And you have the temerity to call *me* a liar. Foo!
In article <jeAA8.16651$GG6.1048...@news3.calgary.shaw.ca>, "Coby Beck"
<cb...@mercury.bc.ca> wrote: > While I agree heartily with Erann's post in this context, the above takes a > philisophical bent I have never really thought fair. It is summed up in the > catch phrase "If you're not part of the solution, you're part of the > problem"
I would say it slightly differently: if you *choose* not to be part of the solution then you are part of the problem. If you are unable to be part of the solution then that (but only that) absolves you of responsibility. IMHO.
> I have always prefered to rephrase that as "If you're not part of the > problem, you're part of the solution" I believe that is better as we are > ultimately only responsible for our own actions (and inactions).
It's the "inaction" part that makes it all very slippery.
I don't know whether this is making the papers outside this country, but here in the US the Catholic Church is currently embroiled in a scandal involving priests who sexually abuse children. At the epicenter of the scandal is Cardinal Bernard Law of Boston, who knew this sexual abuse was going on for years and did nothing to stop it. Does he bear any responsibility? After all, he's only responsible for his own actions, and he wasn't the one doing the raping.
It is astonishing to me that there is actually debate over this issue.
> > Question 2.9: "How are structure passing and returning > > implemented?"
> > Answer (for the passing half): "When structures are passed > > as arguments to functions, the entire structure is typically > > pushed on the stack, using as many words as are required. > > (Programmers often choose to use pointers to structures > > instead, precisely to avoid this overhead.) Some compilers > > merely pass a pointer to the structure, though they may have > > to make a local copy to preserve pass-by-value semantics.
> this is an implementation detail. i don't believe either C standards > specify what to do to preserve pass-by-value semantics. both just > specify the semantic. moreover, if the compiler can tell that no > assigments are made to the structure, it is under no oblication > to make a copy.
Of course. I assume that you are expanding the scope in agreement with what I said. My emphasis (which you snipped) was that the pass-by-value semantics are key. Most languages have the leeway to optimize away actions when it can be determined that the semantics are preserved. In fact, in CL the compiler is allowed to not even call the specified function, as long as the semantics are preserved _as_ _if_ the call had been made. This allows transformations from heavyweight functionality to lighter weight functional implementations.
-- Duane Rettig Franz Inc. http://www.franz.com/ (www) 1995 University Ave Suite 275 Berkeley, CA 94704 Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
> When you start talking > about what happens inside and how it's hidden by the surface language...
This whole thread reminds me of VAX/VMS. It has been a while, but DEC did something cool with the languages they developed for VMS. they came up with a standard call interface so inter-language calls were nothing special. Except that one /did/ have to dig into stuff normally hidden by the surface language.
If I was writing VAX BASIC and I wanted to call an OS routine (I 'spose written in Macro, the VAX assembler, but it doesn't matter) I had to look at what the OS function wanted (in the universal terms of the standard calling convention, then look to the BASIC User Guide for the default passing mechanism to see if they aligned.
In some cases I had to take the address of a Basic thingy with the LOC function, but most of the time the default passing mechanism turned out to be just dandy. COBOL had CALL...USING x BY REFERENCE y BY VALUE.
The punch line is that, IIRC, what I took to be call by reference (passing a pointer) would be documented as a long being passed by value. The doc would then say "the address of whatever". That really pissed me off back then, but thx to this thread I now see why that was necessary.
fwiw, this anecdote does not contradict either side, which is my larger point.
--
kenny tilton clinisys, inc --------------------------------------------------------------- "Harvey has overcome not only time and space but any objections." Elwood P. Dowd
> The fact is that people come to languages with very different > backgrounds, and Lisp at least seeks to be a language of the common > man, not just of CS elitists--at least, _I_ want that of it. And so > I will not put CS formalist terminology in between a potential Lisp > convert and their success. The Scheme community seems to not mind > doing this, and this is one of many ways I generally prefer myself > associated with this political party rather than that one...
What I think is also ironic is that the issues being discussed here--argument passing semantics--aren't nearly as relevant to being a competent Lisp programmer as they are to being competent in just about any other language.
I see an awful lot of confusion about this sort of thing with Delphi programmers who I work with at MegaCorp--Delphi by default uses different conventions then the rest of the universe, so interfacing to foreign code can be tricky for novices. In addition to a C++ like "feature" of being able to declare individual arguments as "pass by reference," there are no fewer then *five* different qualifiers available to change the semantics of how a method/procedure/function should pass expect its arguments to be passed.
Lisp gets it so very right: there's no worrying about what's been stack allocated and what's been heap allocated, no worrying about if the function you just called is going to modify the integer you passed it, you can return multiple values by returning multiple values instead of having an "argument" be a return value, etc.
Languages that don't get it right put a huge burden on the programmer right off the bat--a burden that I don't think novices should have to deal with until they understand a host of other things...
g...@jpl.nasa.gov (Erann Gat) writes: > Maybe. Do you have the knowledge and the means to do something about > world hunger? If you do and you chose not to do anything then yes, I > blame you for world hunger (to the extent that it exists because you chose > not to do what you could).
> I *do* know that you have the knowledge and the means to write books about > C.
"Means" include time and sufficient interest. I have neither. People do have to prioritize their resources. Writing yet another C books is very, very low on my priority list. (I should probably also cut down on my participation in this thread...)
> Hogwash. It's so non-trivial you had to resort to Latin to even > *describe* the process. But even if the *description* of the process is > trivial doesn't mean the process itself is trivial. (If you want to claim > that the process is trivial then you should post the code that will > automatically convert my C code to the new argument passing convention.)
Oh, you want an automatic converter? Now that's something quite different. I was thinking of writing my C code with Lisp value representations in mind in the first place. Doing so is at most a tiny fraction harder than writing "normal" C code.
> But all this is moot because your solution is not even *correct*. It > reproduces only one aspect of Lisp's calling semantics (the easy part), > and my claim was that reproducing "all aspects of Lisp's argument passing > semantics in C++" is a substantial amount of work. That includes things > like &rest and &key.
Oh, come on now! This has nothing to do with what we were talking about. Next thing you are probably going to insist in being able to call your C functions without commas to separate the arguments...
> So you are wrong. Top to bottom, end to end, no matter how you slice it, > wrong.
All right, I am wrong. Lisp does not have call-by-value semantics because &key and &rest are difficult to emulate. Now, there you have it. Happy?
> > While I agree heartily with Erann's post in this context, the above takes a > > philisophical bent I have never really thought fair. It is summed up in the > > catch phrase "If you're not part of the solution, you're part of the > > problem"
> I would say it slightly differently: if you *choose* not to be part of the > solution then you are part of the problem. If you are unable to be part > of the solution then that (but only that) absolves you of responsibility. > IMHO.
What if you can be part of the solution for either problem X or problem Y, but not both. If you choose X, are you now to blame for Y?
> I don't know whether this is making the papers outside this country, but > here in the US the Catholic Church is currently embroiled in a scandal > involving priests who sexually abuse children. At the epicenter of the > scandal is Cardinal Bernard Law of Boston, who knew this sexual abuse was > going on for years and did nothing to stop it. Does he bear any > responsibility? After all, he's only responsible for his own actions, and > he wasn't the one doing the raping.
This is quite different. If it were my job and duty to eradicate misconceptions about the C language from this world and if I then fail to do so, I am guilty. But it is neither my job nor my duty, so give me a break!
The question of whether or not Law is to blame in the sex scandal boils down to whether or not it was his duty to stop his minions, or to report them to the police. I agree with you that the spectacle around this is astonishing.
> > No, this is not what I'm trying to say. In Lisp the list (1 2 3) > > is very well-defined to be not one value, but three values: > > 1. a cons cell whose car contains 1 and whose(2 3), > > 2. a cons cell whose car is 2 and whose cdr contains (3), and > > 3. a cons cell whose car is 3 and whose cdr is nil.
> > If Lisp were pass-by-value, then one whole cons cell would be copied > > on passing (like a C struct).
> No, there is no Lisp equivalent to a C struct variable!
It is this difference (the extra complexity that entire structs are "values" in C, whereas other arrays and strings are not) that make it inappropriate to say that C and Lisp calling sequences are the same.
In order to call Lisp call-by-value (or even C, for that matter), you would have to define "value". You have made implications and descriptions to this effect, but you have never once offered any actual references defining what a value is in C, let alone Lisp. Please find me any precise definition of value for either C or Lisp.
> > > It does not cause any problems. What causes problems for you is that > > > you do not seem to have a very good grasp of the concept of "value".
> > And, of course, you do. Unless you can back your claims, I guess we'll > > have to agree to disagree.
> I think I do. You are welcome to disagree, of course.
I do disagree, of course - you have not backed your claims at all. In this whole thread up to the time I am writing this response, you have not once mentioned any references to back up the facts you are purporting. (you did come close once, citing two authors, but that's not a reference; if you were to put that in a bibliography on a test, I would have thrown that reference out). Unless and until you back your arguments with references, you will have failed to convince me of your positions.
-- Duane Rettig Franz Inc. http://www.franz.com/ (www) 1995 University Ave Suite 275 Berkeley, CA 94704 Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Matthias Blume <matth...@shimizu-blume.com> writes: > ... Just make sure that you use terms that actually > describe accurately what's going on in Lisp, but don't coin new terms > for things for which there are perfectly good language-independent > terms available. "Call-by-value" is an example for such a term.
For varying values of "perfectly good".
I'm reminded of graffiti I saw scribbled on the wall of a toilet stall when I first arrived at MIT:
> > At the surface level, it is pointless and a distraction to teach it this > > way.
> Certainly. But a completel understanding of programming languages > usually requires something more than just the surface level.
To be clear, this discussion didn't arise from someone trying to discuss the complete understanding of all languages. It arose from someone taking exception to my attempts to help a newbie to Lisp get past a specific conceptual problem and become a competent programmer in CL. As such, I claim the moral high ground as to the purposeful context of my remarks.
If someone wants to start a new thread about how theorists should view it, that's an utterly different discussion.
* Erann Gat | So yes, you can take the blame for every omission and mistake of others | precisely because you have not filled in the gap or provided the | correction. If not you, then who?
Not all cultures believe in the necessity of a guilt trip to get to Heaven. Sometimes, there simply is no one to _blame_, nothing to be or feel guilty for. Some cultures are evidently unable to deal with a lack of someone to blame and even go on to believe in religious figures who assume this role on behalf of others. Members of those cultures go on to _produce_ malevolence and misery with their fault-finding missions, where the designated blamee must bear the brunt for all the ills of the world. The Biblical story of the scapegoat is worth knowing and remembering for people who have to deal with members of such cultures.
Reasonable people will reject these theories of blame, guilt trips, and scapegoats as inherently anti-moral instruments of abusive power, the likes of which have been expelled from the West ages ago, but which still causes wars to be raged in the region of their origin.
Quit bringing your offensive blame and guilt crap to comp.lang.lisp. -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.
70 percent of American adults do not understand the scientific process.
> > Coby didn't say you were uneducated; just the opposite. His statement > > does not appear to be about _you_, it's about the subjective goodness > > of the situation in which you find or place yourself.
> I know what he wrote. He basically harped on the old "ivory tower" > thing, with more than just an innuendo that I might have lost touch > with reality because of whatever education I might have. I find that > rude.
Only arrogance finds criticism rude. You have made many bold and dismissive claims about other people's view points and repeatedly appealed to authority that you refuse to cite. It warrants being blunt. (which was my intention, not rudeness).
And you should re-read what I wrote, it has just about zero to do with the "ivory tower" thing. It is about how language and education can actually inhibit the ability to think and the ability to communicate with people from other backgrounds. It is a linguistic and philisophical issue, not a class issue.
(I almost said "think outside the box" but these days, that's pretty much inside the box ;)
In article <for8ktkmu7....@blume-pcmh.research.bell-labs.com>, Matthias
Blume <matth...@shimizu-blume.com> wrote: > All right, I am wrong. Lisp does not have call-by-value semantics > because &key and &rest are difficult to emulate. Now, there you have > it. Happy?
No, because that's not what you're wrong about. You're right, Lisp *does* have call-by-value semantics. (I said so at the beginning of this discussion.)
What you're wrong about is your apparent belief that it is reasonable to expect a C programmer to obtain an accurate understanding of how Lisp function parameters work by saying simply, "It's call-by-value, just as in C" and leaving it at that. Yes, you are technically correct, but it doesn't help a C programmer understand why when he passes a struct by value he gets a copy of the struct, but when he passes a list by value he doesn't get a copy of the list.
This is not about technicalities. This is about pedagogy. It's not about being right. It's about helping people understand. What you're wrong about is your belief that those two things are the same.
In article <fon0vhkmjq....@blume-pcmh.research.bell-labs.com>, Matthias
Blume <matth...@shimizu-blume.com> wrote: > > I would say it slightly differently: if you *choose* not to be part of the > > solution then you are part of the problem. If you are unable to be part > > of the solution then that (but only that) absolves you of responsibility. > > IMHO.
> What if you can be part of the solution for either problem X or > problem Y, but not both. If you choose X, are you now to blame for Y?
Yep. Life's full of tough choices.
> > I don't know whether this is making the papers outside this country, but > > here in the US the Catholic Church is currently embroiled in a scandal > > involving priests who sexually abuse children. At the epicenter of the > > scandal is Cardinal Bernard Law of Boston, who knew this sexual abuse was > > going on for years and did nothing to stop it. Does he bear any > > responsibility? After all, he's only responsible for his own actions, and > > he wasn't the one doing the raping.
> This is quite different. If it were my job and duty to eradicate > misconceptions about the C language from this world and if I then fail > to do so, I am guilty. But it is neither my job nor my duty, so give > me a break!
I wouldn't compare what you're doing to what Cardinal Law did; that example was strictly to refute Coby's moral stance. However, I would say that if you disclaim responsibility for clarifying misconceptions about about C then you have no basis for complaint when those who do choose to take on the task of clarifying those misconceptions do so in a manner that is not to your liking. Put up or shut up. It's very annoying for those who are trying to clear this up to have to deal with pot shots -- well informed though they may be -- lobbed from the sidelines.
Duane Rettig <du...@franz.com> writes: > > No, there is no Lisp equivalent to a C struct variable!
> It is this difference (the extra complexity that entire structs are > "values" in C, whereas other arrays and strings are not) that make > it inappropriate to say that C and Lisp calling sequences are the > same.
This is not correct. The important difference that accounts for much of the misunderstanding is that the locations of an entire struct can be denoted by a variable in C, but not in Lisp. While this is a difference, it does not make it inapropriate to say that C and Lisp parameter passing semantics are the same. In fact, the meaning of "call-by-value" gives you C semantics when applied to the C meaning of variables (including those of struct type), and it gives you Lisp semantics when applied to the meaning of Lisp variables (of which there are none that denote structs).
In your choice of words ("calling sequences") I detect that you still are confused about the very subject of our discussion. We are not talking about "calling sequences". We are talking about the semantics of parameter passing. Calling sequences are a concrete means of implementing parameter passing semantics, but there is no 1-1 mapping between the two.
I have explained several times what the distinction is between cbv, cbr, and cbn. I have also pointed out that the distinction does not depend on the nature of values. Instead, it characterizes how formal parameters relate to their respective actual arguments (or argument expressions).
> In this whole thread up to the time I am writing this response, you > have not once mentioned any references to back up the facts you > are purporting.
These things are standard CS terminology. You can read about them in any textbook on PL semantics. To give you something concrete to look at, I recommend having a look at the definition of Scheme. The authors of the Scheme report makes a very strong effort at being precise by actually giving a formal denotational semantics. Now, Scheme is not a Lisp :-), but as far as the semantics of parameter passing is concerned, the two are close enough. So have a look at the denotational semantics section of, e.g., R5RS. (The report also comes with numerous references to relevant literature. You will probably need those because my guess is that you will be familiar with neither the notation nor the theory used in that section.)
> (you did come close once, citing two authors,
You mean "Harbison and Steele"? This is almost as well-known as K&R, sometimes even similarly abbreviated as H&S. Of course, I did not give you a bibtex entry for it. I am not publishing a paper here.
> but that's not a reference; if you were to put that in a > bibliography on a test, I would have thrown that reference out).
What "test"? Am I being tested here? :-)
> Unless and until you back your arguments with references, you will > have failed to convince me of your positions.
In article <3229449622411...@naggum.net>, Erik Naggum <e...@naggum.net> wrote: > * Erann Gat > | So yes, you can take the blame for every omission and mistake of others > | precisely because you have not filled in the gap or provided the > | correction. If not you, then who?
> Not all cultures believe in the necessity of a guilt trip to get to > Heaven. Sometimes, there simply is no one to _blame_, nothing to be or > feel guilty for. Some cultures are evidently unable to deal with a lack > of someone to blame and even go on to believe in religious figures who > assume this role on behalf of others. Members of those cultures go on to > _produce_ malevolence and misery with their fault-finding missions, where > the designated blamee must bear the brunt for all the ills of the world. > The Biblical story of the scapegoat is worth knowing and remembering for > people who have to deal with members of such cultures.
The difference is that the scapegoat didn't go around calling people liars because they tried to educate others in ways that it didn't approve of.
> Quit bringing your offensive blame and guilt crap to comp.lang.lisp.
> Oh, you want an automatic converter? Now that's something quite > different. I was thinking of writing my C code with Lisp value > representations in mind in the first place. Doing so is at most a > tiny fraction harder than writing "normal" C code.
> ... The mistake is to assume, as newly > elected Presidents of the US often do, that the mere fact of election > to office construes mandate or even approval of all of one's detailed > agenda; it just means that the entire package, taken as a whole, was > better than another entire package.
but the question had to do with the historic practice of the community, not some arbitrary approval of a political point or agenda everyone grumbled about afterwards. in that long post [i did not duplicate] i understand you to be saying that in the last twenty or thirty years, lisp community [a much abused term, that] disagreed with its language designers, authors, theorists in terminology, or that all of that terminology was mere politics on the part of whomever used it for whatever reason. people like steele and gabriel have talked about evolution of lisp in great adetail[1] but i don't recall any mention of any such fundamental terminology problem. when did it start? in the CL standards work?
oz --- [1] Bergin & Gibson, "History of Programming Languages", Addison Wesley, 1996
