> > ... It's very hard to > > find a good definition of the word "binding" (as a noun) in published > > works.
> umm, i don't know. i'm not sure if you'd like these, but here is just > a few from my own library:
> Pratt & Zelkowitz, "programming languages: design and implementation" > from pp. 50 onwards, on "binding and binding time"
> appel, "modern compiler implementation in *" > from pp. 103 onwards, "symbol tables"
> mclennan, "principles of programming languages" > eg. pp 363 onwards, "design: name structures"
> friedman, wand, haynes, "essentials of programming languages" > eg. pp 28 onwards, "scoping and binding of variables"
> it took me longer to type these lines than to actually find them.
I don't think your collection is typical. I doubt one working programmer in three has even one of those books, let alone all four. The only one of these that I own is EOPL, and in my copy, page 28 has no subject headings at all. Page 29 starts a section called "variable arity procedures." (Is there more than one edition?) The "definition" of binding is given on page 2. (I put "definition" in scare quotes because it isn't really a definition, just an example of canonical usage.)
> One big obstacle, I think, is that at the time the terms "call by > value", "call by reference", and "call by name" were invented, pretty > much all variables in all languages were statically typed, of known and > fixed size, and either statically allocated at absolute addresses or at > a fixed offset from some base register.
this is just not true. please, please just go to any CS library and read up. maybe just find a copy of allen: CBV and CBN are both covered nicely.
oz --- the most underused tool in the kitchen is the brain. -- alton brown
g...@jpl.nasa.gov (Erann Gat) writes: > I don't think your collection is typical. I doubt one working programmer > in three has even one of those books, let alone all four.
well, i'm not sure what you meant by published works, so i've picked some general PL books, as per topic. that is what a working programmer with any interest in PL terminology and technology would probably reach for, not some IDIOT's* guide.
yes, there is a second edition of EOPL. the discussion there seems pretty good to me, but it is not a dry dictionary definition.
oz --- * note that not all IDIOT's guides are created equal: those interested in writing and publishing science fiction should find a copy of Cory Doctorow and Karl Schroeder's "the complete idiot's guide to publishing science fiction" and ignore any strange stares. it is simply one of the best books on the topic. Schroeder recently also published "ventus" and "permanence."
> > One big obstacle, I think, is that at the time the terms "call by > > value", "call by reference", and "call by name" were invented, pretty > > much all variables in all languages were statically typed, of known and > > fixed size, and either statically allocated at absolute addresses or at > > a fixed offset from some base register.
> This is nonsense. Lisp is the second oldest computer language still > in common use and call-by-value, call-by-reference and call-by-name > are decades old concepts and terms. As Matthias Blume has already > pointed out, people in and around the lisp community were those who > initially developed these ideas and terminology. Lisp was the > canonical example of cbv and Algol-60 was (and still is) the canonical > example of cbn.
You need to look outside the Lisp community. Lisp is just *one* programming language (or a small family), and historically a rather poorly known one and not very influential outside its niche in academia. I certainly know its age, and I also know that the other major languages of that time -- FORTRAN and COBOL are as I describe them. So is Algol 60, for that matter. Languages didn't change much until the Algol 68/C/Pascal era, and by that time the terminology was already well fixed.
> Typing issues are completely orthogonal to cbv parameter passing, and > so are allocation and stack frame details.
No they are not. When you know exact details of the type and lifetime of values you can make significant optimizations over their allocation. Only extremely sophisticated Lisp compilers make these optimizations, but in FORTRAN and COBOL (for example) these optimizations are not even thought of as optimizations because the langauge specification defines away the possibility of dynamic types and dynamic lifetimes.
> One big obstacle, I think, is the insular nature of the lisp > community.
"Coby Beck" <cb...@mercury.bc.ca> writes: > When arguing about the correct name for something there are only two (often > unresolvable) approaches: argument by authority and argument by consensus. > You aren't appealing to consensus but you have not provided any citations to > support what you say, so it can not yet be convincing.
I haven't checked Matthias' definitions word for word but on first reading they certainly seemed similar to my memory of the definitions found in books on denotational semantics. I checked the following four to see that they do have sections on parameter passing that describe (denotationally) what call by value, call by reference, ... etc. mean :-
@book { Watt:plss:1991 , author= "David A. Watt" , title= "Programming Language Syntax and Semantics" , publisher= "Prentice-Hall" , year= 1991 , refs= 58 , source= "own" , checked= 19960310 , isbn= "0-13-726274-4" , blurb= "Programming Language Syntax and Semantics introduces methods for formaly specifying the syntax and semantics of programming languages.
Chapter 2 introduces the topic of syntax, covering both context-free grammars and regular expressions. Chapters 3-5 introduce denotational semantics, the most commonly used method for specifying semantics. Chapter 6 introduces algebraic semantics, applying it to specify new data types. Chapters 7-8 introduce action semantics, a new method that promises to make semantic specifications unusually readable. the text concentrates on practical specification techniques, but the underlying theory is briefly covered where appropriate.
Numerous examples, exercises, and case studies support the text."
}
@book { Kirkerud:pls:1997 , author= "Bj{\/o}rd Kirkerud" , title= "Programming Language Semantics: Imperative and Object Oriented Languages" , publisher= "Thomson" , year= 1997 , refs= 32 , pages= 347 , source= "own" , checked= 19970201 , cost= "UKP 23.95" , isbn= "1-85032-273-2" , blurb= "{\em Programming Language Semantics} is designed to provide a formal introduction to the semantics of programming languages for readers with little or no prior experience of the subject. Focusing mainly on denotational semantics, the author also explains operational and axiomatic semantics.
The book explains how to define semantics of imperative programming languages. A chapter on objects and clsses is also included, providing the formal definitions of the semantics of object oriented languages. The functional language ML is used to implement some of the formal definitions given in the book."
In article <3229595420030...@naggum.net>, Erik Naggum wrote: > | I had read your previous post about 'the standard three' and I thought I > | got them right. I have a mental model of Lisp's argument passing, which > | seems very natural and intuitive. However, my understanding was that it's > | different from C's argument possing model which involves 'copying' of an > | argument.
> Well, no, C's does not involve copying, it just passes all struct members > as individual arguments, as in destructuring. I guess a destructured > pass by value looks a lot like a copy, and I guess this whole messy > argument passing thing in C has confused a lot of people, what with > arrays being passed by value but as references, with pointers being > passed by value but being references, and struct being passed by value > but as values.
These are what I wanted to know -- C's model. It's all clear now. Thank you. I think the above and your summary of pass-by-XXXs would make a good entry for a FAQ.
abe
-- "What we hear constantly is that after September 11th, everything changed. There is a good rule of thumb: if something is repeated over and over as obvious, the chances are that it is obviously false." -- Chomsky <http://www.zmag.org/content/ForeignPolicy/chomsky_march26.cfm>
In article <3229606270797...@naggum.net>, Erik Naggum <e...@naggum.net> wrote: > | They read K&R and Stroustrup or C++ for Dummies, and as a result they > | have no idea what a binding is. And it's not their fault. It's very > | hard to find a good definition of the word "binding" (as a noun) in > | published works. If you don't believe me, time yourself to see how long > | it takes you to find one (not including the Hyperspec, of course).
> H.P.Barendregt: The Lambda Calculus, Its Syntax and Semantics. 1 second. > (It is within reach from where I sit.)
Well, *there's* a book that's undoubtedly at ready hand to every working programmer.
[Snip]
> By this time, I had spent 20 minutes pulling some 30 books out of my > 1100-volume strong personal library and had found 12 hot hits. So not > only did I know roughly where to look, it was where I thought I would > find it. If any the other books also have a description of binding, I do > not know, but I am not at all unhappy with the hit rate.
Are you arguing in support of my position or against it? A hit rate of one in three out of books hand-picked by an expert out of an extensive personal library is the *best* one could hope to achieve. The more typical situation is probably closer to randomly browsing the computer section at Barnes and Noble.
In article <3229608336004...@naggum.net>, Erik Naggum <e...@naggum.net> wrote: > * Erann Gat > | Perhaps, but that still doesn't justify saying "It's call by value. > | Period." At best, "It's call by value, and all the values are pointers > | that are automatically dereferenced every time you refer to them." But > | even that isn't entirely true because...
> Please listen. Call _by_ value is different from call _with_ value.
That's news to me. I've never heard of this distinction before. Could you please cite a reference?
> The > meaning of "value" is irrelevant. The fact that you cannot access the > _binding_ of the value is the clue. In call _by_ reference, you do not > pass _some_ references to objects, you pass references to _bindings_.
Yes, I understand that, but I think you've missed the point. The point is not whether Lisp is call-by-value or not. I concede that it is. The point is that the apparent behavior of Lisp and C is different. That difference has to be accounted for somehow if you're going to try to teach Lisp to C programmers. There are various ways to account for this difference. Kent's approach is to invent a new story about argument passing that he calls "call-by-identity". Matthias's approach is to talk about the underlying implementation of Lisp values as pointers. And your approach is (apparently) to focus on the distinction between values and bindings.
My point is that none of these approaches is inherently superior to the others, and that the standard by which they should be judged is how effective they are in helping people understand. My personal intuition is that Kent's approach seems most promising on this metric, but the only way to resolve the issue is to do some actual experiments with actual C programmers.
In article <bruce-0E6C86.12260006052...@copper.ipg.tsnz.net>, Bruce Hoult
<br...@hoult.org> wrote: > I'm convinced it's more a terminology problem than an actual > understanding problem.
I don't think you can separate the two.
> Yes, Lisp arguments are "call by value", but that is not at all enough > to understand them because all the values are pointers (which Lisp calls > "bindings") and the things that Lisp calls "values" are the heap objects > pointed to by those pointers.
This is a perfect illustration of how terminology problems *are* understanding problems. Your definition of binding here...
> values are pointers (which Lisp calls "bindings")
is at odds with the definition given in the Hyperspec:
> binding n. an association between a name and that which the name denotes.
Your definition also contains a "type mismatch" error: pointers are first-class entities. Bindings are not.
> H.P.Barendregt: The Lambda Calculus, Its Syntax and Semantics. 1 second. > (It is within reach from where I sit.)
* Erann Gat | Well, *there's* a book that's undoubtedly at ready hand to every working | programmer.
I sense hostility even when I try to answer your questions seriously.
The only book I have within reach that is for a working programmer is the first edition of "ML for the Working Programmer", but I ignored that book because MLS is not for the working programmer. You obviously have such an exclusive definition of "working programmer" that it is impossible to refute your claim by actually finding a commonly available book with a good definition. This speaks volumes about the sincerity of your claim.
| Are you arguing in support of my position or against it?
Again, I sense hostility even when I try to answer your questions seriously. What do you think this tells me?
| A hit rate of one in three out of books hand-picked by an expert out of | an extensive personal library is the *best* one could hope to achieve.
Well, you have chosen a fairly technical term. Her's another obvious answer to those in the pharmaceutical industry and quite a number of concerned users: In which common househould products would you find hexachlorophene, and if you know that it also the active ingredient in medication administered orally to cats, what is the ailment for which it is the therapy? Where would you start looking? There is _one_ reference work that a self-respecting physician or pharmacologist should have ready access to that answers this question. Which is it?
| The more typical situation is probably closer to randomly browsing the | computer section at Barnes and Noble.
Do engineers who need to know the tensile strength of a steel quality go to Barnes & Noble? My question here is really: Why is a computer programmer expected to be an illiterate fool and why are you basing your entire argument on the ignorance of the common programmer? And this after "blaming" Matthias Blume for not writing textbooks for these people, when they would clearly not even touch it if it were for sale?
Are programmers responsible for their own skills? That is what this silly book hunt really boils down to. Your answer is a resounding No. Mine is an equally resounding Yes. -- 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.
* Erann Gat | That's news to me. I've never heard of this distinction before. Could | you please cite a reference?
It was intended to make you think. It did not work this time, either. I am sorry that you need somebody else to tell you the same thing I do before you can muster the brainpower to think about something. Your curious selectivity in asking for references is quite telling. It is a sort of passive-aggressive behavior that I associate with cowards who think they can get away with their not-so-veiled hostilities.
| Kent's approach is to invent a new story about argument passing that he | calls "call-by-identity".
Did he provide any references for this novel term? Why do you ask for references as a means of terrorizing people into silence when it is so obvious that you are being a hostile prick even when people try to deal with you as the intelligent being you once were and actually try to answer your mostly retarded questions seriously?
Geez, I keep making the mistake of believing you will recover, somehow. -- 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.
In article <gat-0605021030520...@k-137-79-50-101.jpl.nasa.gov>, g...@jpl.nasa.gov (Erann Gat) wrote:
> In article <bruce-0E6C86.12260006052...@copper.ipg.tsnz.net>, Bruce Hoult > <br...@hoult.org> wrote:
> > Yes, Lisp arguments are "call by value", but that is not at all enough > > to understand them because all the values are pointers (which Lisp calls > > "bindings") and the things that Lisp calls "values" are the heap objects > > pointed to by those pointers.
> This is a perfect illustration of how terminology problems *are* > understanding problems.
You're implying that I don't understand Lisp bindings and values? That would be a very strange thing if true, since I'm a member of the core team working on a Lisp-family compiler.
> Your definition of binding here...
> > values are pointers (which Lisp calls "bindings")
> is at odds with the definition given in the Hyperspec:
> > binding n. an association between a name and that which the name denotes.
In fact I specifically coined that definition to match that section of the HyperSpec.
> Your definition also contains a "type mismatch" error: pointers are > first-class entities. Bindings are not.
The term "first class" is relevent only to things that are defined in the Lisp language. "Pointers" in fact do not exist in the Lisp language at all, they are merely an artifact of typical implementations. Bindings in the source code are translated into machine code in one of two ways: by optimizing them away entirely, or by representing them as machine pointers.
> "Joe Marshall" <prunesqual...@attbi.com> writes a very interesting > post demonstrating the difference between call-by-value and > call-by-reference.
> I am not an assembly language programmer [it's on the list of > things to do], so I have a few quick questions regarding the > assembled output listed below:
> > ff 75 e4 pushl [ebp-28] ; push contents of X
> > FF 75 F8 pushl [ebp-08h] ; push contents of X
> > 8B 45 FC movel eax, [ebp-4] ; contents of X is EAX
> > ff 75 fc pushl [ebp-08h] ; push contents of X
> > 8d 7d fc lea -4(%ebp),%edi ; compute address of X > > 57 push %edi ; push it
> So the first 4 lines [3 from CL implementations, 1 from C] I > quoted involve copying the "value" of X onto the stack before > calling function bar. What happens if the "value" of X does not fit > in a long-word?
Good question. In every Common Lisp implementation I have seen, the value is *always* a long-word. (Acutally, I've seen a couple that used two long-words.) This is so that you can have runtime polymorphism. Since any value can be placed in any variable, all values have to be the same size.
So in Lisp, X is guaranteed to fit in a long-word.
In C if the type of X is bigger than a long-word, you will have more memory moving going on. If it is less, you *might* have less, or it could have been `expanded' to a long-word.
> The second question is how does the last LEA instruction work to > compute the address? Is this an x86 architecture?
Yes, it is x86, but I've seen LEA on other (non-RISC) architectures. It works by causing the address computation hardware to compute the address, but rather than putting the result on the bus, it puts it in a register. It's basically an adder, but since it knows about word sizes, it can shift one of the addends by one or two bits.
Some people have noticed that you can use it as an adder for extra performance because it doesn't use the same datapaths as the ALU. You can squeeze an extra addition through the pipeline if you are clever. (Or desperate, or have too much time on your hands.)
k...@ma.ccom (Takehiko Abe) wrote in message <news:keke-0505021225530001@solg4.keke.org>... > In article <dvXA8.66989$%s3.26566...@typhoon.ne.ipsvc.net>, "Joe Marshall" <prunesqual...@attbi.com> wrote:
> > > > > Common Lisp doesn't copy its parameter, which is different from C.
> > > > Of course it does. If I write
> > > > (defvar x <something>) > > > > (defun f (y) (setq y <something else>)) > > > > (f x)
> > > > then f receives a copy of the contents of x.
> > > No, it doesn't. f receives the contents of x, not a copy of it. If that > > > <something> is mutable, you can modifiy it in f.
> > If F did not receive a copy of the contents of x, then it wouldn't > > be in X anymore.
> My understanding is that F receives the location of the contents, so > both X and Y can share it.
What I mean is this: The value cell of the symbol X is somewhere in memory. Let's say it is at location 100. The variable Y doesn't need a symbol associated with it, so it's value is going to be on the stack, say location 5000.
In the value cell of X, there is a 32-bit word. It is likely a pointer to something, but it doesn't matter.
Now when we call F, we read the 32-bit word out of location 100 and copy it into location 5000. It is *this* copy that makes the call `call-by-value'.
Our other option would be to put the number 100 into location 5000. Then Y would not have a copy of X, but the address of X. This would be call-by-reference.
> > When F is running, there are two variables of > > interest, x and y. Both contain the same thing, yet they are not > > the same location.
> This is where I lost track. I think they hold the same location.
If X contains an address, then after the copy, Y contains the address, too. If X *doesn't* contain an address, then Y won't either. What the 32-bits ultimately mean is unimportant. What is important is whether Y gets loaded with the same thing that is in X (call-by-value), or whether Y gets loaded with the address of X (call-by-reference).
> > In article <bruce-0E6C86.12260006052...@copper.ipg.tsnz.net>, Bruce Hoult > > <br...@hoult.org> wrote:
> > > Yes, Lisp arguments are "call by value", but that is not at all enough > > > to understand them because all the values are pointers (which Lisp calls > > > "bindings") and the things that Lisp calls "values" are the heap objects > > > pointed to by those pointers.
> > This is a perfect illustration of how terminology problems *are* > > understanding problems.
> You're implying that I don't understand Lisp bindings and values? That > would be a very strange thing if true, since I'm a member of the core > team working on a Lisp-family compiler.
I wasn't intending to cast any aspersions on your professional qualifications. I was just responding to your earlier comment:
> I'm convinced it's more a terminology problem than an actual > understanding problem.
The emphasis should be on "terminological problems *are* understanding problems", not so much on the particular example.
Also, there are different kinds of understanding. The kind of understanding you need to get something done is different from the kind of understanding you need to communicate your understanding to someone else. (See Richard Feynman's writings on science education.) The topic at hand here is more the second kind of understanding.
> > Your definition of binding here...
> > > values are pointers (which Lisp calls "bindings")
> > is at odds with the definition given in the Hyperspec:
> > > binding n. an association between a name and that which the name denotes.
> In fact I specifically coined that definition to match that section of > the HyperSpec.
Well, then I'm confused. You say that values==pointers==bindings. But in the Hyperspec values!=bindings.
> > Your definition also contains a "type mismatch" error: pointers are > > first-class entities. Bindings are not.
> The term "first class" is relevent only to things that are defined in > the Lisp language. "Pointers" in fact do not exist in the Lisp language > at all, they are merely an artifact of typical implementations. > Bindings in the source code are translated into machine code in one of > two ways: by optimizing them away entirely, or by representing them as > machine pointers.
OK, I think I understand. So now we have *three* theories of how Lisp arguments work. (And all of them are right!)
In article <gat-0605021852040...@192.168.1.50>, g...@jpl.nasa.gov (Erann Gat) wrote:
> Well, then I'm confused. You say that values==pointers==bindings. But in > the Hyperspec values!=bindings.
Well, no, I don't say that.
What I'm saying is (among other things) that if Lisp is "call by value" (which I agree that it is, in the sense meant by the people who invented the term) then the "values" being referred to are *not* the same as what Lisp documentation calls "values". They are, rather, what Lisp documentation calls "bindings", where bindings are an indirect mechanism used to refer to the values.
* Bruce Hoult -> Erann Gat | You're implying that I don't understand Lisp bindings and values?
I am not satisfied to imply it: You demonstrate a serious lack of understanding of several such core issues. This is quite amazing.
| That would be a very strange thing if true, since I'm a member of the | core team working on a Lisp-family compiler.
Gee. How tragic. But strange? No. Using such "credentials" to prove that you have understood something is also quite amazingly ridiculous. -- 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.
> 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.
The compiler has to be careful to follow the ABI (for the architecture it's compiling to) - so as not to break separate compilation. However, the optimisation you mention can be applied to static functions.
Further to the discussion: recall that both C and Lisp are call-by-value. In C, if you want to modify a parameter (in the caller), you pass it's address. This gets you call-by-reference semantics but it's still call-by-value. You have to realise that, in this case, it is the _address_ that is passed by value.
The same applies to Lisp. In not very clear on CL but I think that the value contained in a variable is always an address (as in Python).
steven_s...@users.sf.net (Steven Shaw) writes: > The same applies to Lisp. In not very clear on CL but I think that > the value contained in a variable is always an address (as in Python).
No, as in C, in Lisp, a lexical variable may be compiled away to a register that can even be reserved for that variable only through part of its scope or be in code that is completely removed or transformed, and so, not exist at all in the compiled code.
I don't know what you mean by "as in Python". The python compiler does some very intricate optimizations and elides unused code. If you mean python-the-language, I have no idea what you're getting at.
-- -> -/ - Rahul Jain - \- <- -> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <- -> -/ "Structure is nothing if it is all you got. Skeletons spook \- <- -> -\ people if [they] try to walk around on their own. I really /- <- -> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <- |--|--------|--------------|----|-------------|------|---------|-----|-| (c)1996-2002, All rights reserved. Disclaimer available upon request.
steven_s...@users.sf.net (Steven Shaw) writes: > The same applies to Lisp. In not very clear on CL but I think that > the value contained in a variable is always an address (as in Python).
Not true. Consider fixnums and characters, as represented on most current CL 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)
> > The same applies to Lisp. In not very clear on CL but I think that > > the value contained in a variable is always an address (as in Python).
> Not true. Consider fixnums and characters, as represented on most > current CL implementations.
That's just a performance optimization (hack). The results must be the same AS IF the number or character was stored on the heap and the variable contained a pointer. Which turns out to be easy to do, since fixnums and characters are immutable.
> > The same applies to Lisp. In not very clear on CL but I think that > > the value contained in a variable is always an address (as in Python).
> No, as in C, in Lisp, a lexical variable may be compiled away to a > register that can even be reserved for that variable only through part > of its scope or be in code that is completely removed or transformed, > and so, not exist at all in the compiled code.
Which, once again, are optimizations that are only valid so long as they do not change the results.
In article <5bb0e1b2.0205061724.1113d...@posting.google.com>, prunesqual...@attbi.com (Joe Marshall) wrote:
> > > > > then f receives a copy of the contents of x.
> > > > No, it doesn't. f receives the contents of x, not a copy of it. > > > > If that <something> is mutable, you can modifiy it in f.
> > > If F did not receive a copy of the contents of x, then it wouldn't > > > be in X anymore.
> > My understanding is that F receives the location of the contents, so > > both X and Y can share it.
> What I mean is this:
What you meant by "..., then it wouldn't be in x anymore." ?
> [...] > Now when we call F, we read the 32-bit word out of location 100 > and copy it into location 5000. It is *this* copy that makes the > call `call-by-value'.
*That* copy is irrelevant. We were talking about "the contents of x". The contents of x is a Lisp object, and it is not copied.
-- "What we hear constantly is that after September 11th, everything changed. There is a good rule of thumb: if something is repeated over and over as obvious, the chances are that it is obviously false." -- Chomsky <http://www.zmag.org/content/ForeignPolicy/chomsky_march26.cfm>
> > > The same applies to Lisp. In not very clear on CL but I think that > > > the value contained in a variable is always an address (as in Python).
> > Not true. Consider fixnums and characters, as represented on most > > current CL implementations.
> That's just a performance optimization (hack). The results must be the > same AS IF the number or character was stored on the heap and the > variable contained a pointer. Which turns out to be easy to do, since > fixnums and characters are immutable.
This does not change the fact that it is wrong to talk about values always being addresses in CL when dealing with argument passing; it is this mixture of semantics and implementation that causes so much confusion:
1. If you are talking about semantics, it is wrong because addresses are not addressed :-) in CL semantics.
2. If you are talking about implementation, it is wrong because values are not _always_ implemented as addresses.
If you try to mix the two, you will cause confusion.
-- 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)
> > > The same applies to Lisp. In not very clear on CL but I think that > > > the value contained in a variable is always an address (as in Python).
> > Not true. Consider fixnums and characters, as represented on most > > current CL implementations.
> That's just a performance optimization (hack). The results must be the > same AS IF the number or character was stored on the heap and the > variable contained a pointer. Which turns out to be easy to do, since > fixnums and characters are immutable.
I don't think this model is a good idea since Lisp has no concept of pointers as such. To make this work, it needs to be extended to all symbols. i.e.
And the C *still* isn't a correct reflection (not particularly safe either).
C and Lisp have different conceptual models, it's not suprising trying to talk about one in terms of the other leads to so much confusion. Of course, as mentioned in other posts, if C structs were passed the way C arrays were there would be less of a problem.
Forget implementation details, when you pass something in Lisp you pass the actual value, not a copy, not the slot that contains it. You cannot change what has been passed, you can't make a 3 into a 4 or a cons cell into an array. You cannot change what the caller's variable contains since you don't have access to that slot. You do have access to any slots that the actual value contains and any changes are reflected up.
C and Lisp both use pass-by-value only C does a pass-by-copy-of-value and Lisp does a pass-by-actual-value. Referring to Lisp as pass-by-reference is just plain wrong and pass-by-value isn't enough to cover the difference between Lisp and other languages, would anyone settle for calling the differences subcategories of call-by-value?
