Duane Rettig <du...@franz.com> writes: > > 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.
yes, i think. i just wanted to emphasize that call-by-value semantic, even for C should not be read as call-by-value-copy semantic, even though that may be what is commonly implemented.
oz -- Civilization is expensive. --John Kenneth Galbraith
g...@jpl.nasa.gov (Erann Gat) writes: > 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.
Could you, please, quote me saying this. I do not believe the above, and I never (to my knowledge) said that a C programmer would be able to get an accurate understanding of more than this one particular facet of the language by being told that Lisp is call-by-value. In fact, I think I repeatedly said that
1. there are differences in the semantics of the languages
2. that these differences are due to (among other things) the nature of values
So all I was trying to do was to debunk the myth that Lisp has some esoteric parameter passing semantics not to be found in other languages.
> 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.
Indeed, it does not help. It helps even less to explain this phenomenon with the wrong explanation. The correct answer is that a Lisp list is not at all like a C struct.
> This is not about technicalities. This is about pedagogy.
Exactly. I hate the kind of teaching where the teacher tells gentle lies because the students are supposedly not ready to hear the real truth.
> 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
[...]
I'm less sure about this. Pascal, I believe, had pointers without pointer arithmetic. Java, as a currently more popular example, has "references" with approximatrely the same semantics, but you can tell they think they're _really_ pointers, or they wouldn't have a NullPointerException. I don't think "pointer = c pointer" is universal.
(Is Java call-by-value? Do C programmers told that Java has call-by-value semantics get confused because it doesn't copy structure^Wclass fields when an assignment is done from one instance to another?)
Thien-Thi Nguyen <t...@glug.org> writes: > on the other hand, blood is slightly basic and playing w/ its > pH can make you sick. so what is c.l.l, water or blood?
Blood is commonly held to be thicker than water, for what that's worth.
Greg Menke <gregm-use...@mindspring.com> writes: > > 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.
> Greenspun strikes again!
No. Not at all. I don't normally write C code at all, and when I do, then usually not strictly with Lisp-like values. The above exercise was in reply to a question by Erann on how difficult it would be to do it.
> > > 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.
Well, maybe some kind publisher takes my rants here and prints them. Does this count? :-)
"Coby Beck" <cb...@mercury.bc.ca> writes: > Only arrogance finds criticism rude.
... unless the "criticism" is actually an insult, and unless the "criticism" is completely unfounded.
> [...] It is about how language and education can actually > inhibit the ability to think and the ability to communicate with people from > other backgrounds.
Ok, I see. So you accuse me of two things here:
1. That my thinking abilities are somehow inhibited by my education.
Call me arrogant if you like, but this, I think, is rude.
2. That my abilities to communicate with people from other backgrouds is inhibited by my education.
Communication problems can be attributed to one side as much as they can be to the other (unless one side cannot communicate at all, in which case the blame can be placed trivially). There are enough people around here who do understand what I am saying, and there are even more such people who are not following c.l.l. Given that on the "other side" there seem to be enough people who are seriously confused (and have been long before I first said anything, so it was not my communication problem that got them confused in the first place), maybe, just maybe, the problem is with them. Would you not at least accept this as a possibility?
> > > > It's easiest if you think of *everything* as being pass-by-reference.
> > > It may be "easiest", but it is also completely wrong.
> > > Notice that "pass-by-value" (which is the only correct answer to the > > > question) does not imply that the caller cannot change parts of a data > > > structure. The whole question is *only* about how the formal > > > parameter of the function (i.e., within the caller) is related to the > > > actual argument given at the callsite.
> > > Call-by-reference, otoh, would mean that in
> > > (defun f (x) (setq x 2)) > > > (defun g (y) (f y) y) > > > (g 1)
> > > the final answer from calling g would have to be 2.
> > ?? No it would not.
> > Here's the equivilent C code (with types assumed to be integers for > > simplicity):
> > #include <iostream.h>
> > int* f(int *x){return x = new int(2);} > > int* g(int *y){f(y); return y;}
> > This prints "1", just as any Lisp does (CL, elisp, scheme, dylan).
> FYI, this is C++, not C.
Sure. Mostly because the C++ syntax for allocating and initializing a heap object happens to be more convenient than in C.
> Anyway, you see the same effect as in Lisp because your code uses > CALL-BY-VALUE, just like Lisp (and C) does!!
I think you're devaluing the meaning of the term "call by value". At some level every argument passing mechanism ever invented is "call by value" because it consists of copying some bits from an arbitrary place in the caller to some place that the callee knows to look for them.
The only interesting question at the implementation (not conceptual) level is: "*What* is it that is being passed by value?" The integer itself? A reference to where the integer is stored? A reference to some code that knows how to get and set the integer?
The answer in the example above is "a reference to where the integer is stored", just as it is in Lisp.
That's why I'm calling it "call by reference". The things which are passed by value are references to the data, not the data itself.
> Try declaring x as &x.
Unfortunately C++, unlike Lisp, doesn't allow the rebinding of references to new locations.
> At some level every argument passing mechanism ever invented is "call by > value" because it consists of copying some bits from an arbitrary place > in the caller to some place that the callee knows to look for them.
This is not true. In a call-by-reference language the bits that are passed to the callee are *not* a copy of the caller's bits but the address of the caller's bits. The caller's bits are left right where they were. In a call-by-name language there aren't even any bits in the caller. The caller passes a thunk to *compute* the bits if it becomes necessary.
> > At some level every argument passing mechanism ever invented is "call by > > value" because it consists of copying some bits from an arbitrary place > > in the caller to some place that the callee knows to look for them.
> This is not true.
Yes it is.
> In a call-by-reference language the bits that are passed to the > callee are *not* a copy of the caller's bits but the address of the > caller's bits.
The caller either already has those bits stored explicitly in a register or in the current stack frame, or else has those bits implicitly available and regenerates them each time using something such as a LEA/PEA (load/push effective address) instruction.
Either way, they are the caller's bits and they are passed by copying them into the callee.
> In a call-by-name language there aren't even any bits in > the caller. The caller passes a thunk to *compute* the bits if it > becomes necessary.
Exactly as I said in the following paragraph, which you snipped.
"The only interesting question at the implementation (not conceptual) level is: "*What* is it that is being passed by value?" The integer itself? A reference to where the integer is stored? A reference to some code that knows how to get and set the integer?"
> ... unless the "criticism" is actually an insult,
Yes.
> and unless the > "criticism" is completely unfounded.
precisely not.
> > [...] It is about how language and education can actually > > inhibit the ability to think and the ability to communicate with people from > > other backgrounds.
> Ok, I see. So you accuse me of two things here:
Believe it or not, my post, though inspired by you, was not completely about you. see below...
> 1. That my thinking abilities are somehow inhibited by my education.
I did not think this part applied to you. I actually think you know what you are talking about.
> Call me arrogant if you like, but this, I think, is rude.
> 2. That my abilities to communicate with people from other > backgrouds is inhibited by my education.
This, I think, is amply demonstrated by your insistence on technical correctness above all else and you scoffing at people who feel the need for a new terminology.
> Communication problems can be attributed to one side as much as they > can be to the other (unless one side cannot communicate at all, in > which case the blame can be placed trivially). There are enough > people around here who do understand what I am saying, and there are > even more such people who are not following c.l.l. Given that on the > "other side" there seem to be enough people who are seriously confused
I think the people you are engaged with are much less confused than you think.
> (and have been long before I first said anything, so it was not my > communication problem that got them confused in the first place), > maybe, just maybe, the problem is with them. Would you not at least > accept this as a possibility?
I can accept that as a possibility. With that I happily concede to you the last word on this branch of the thread.
Erik Naggum <e...@naggum.net> writes: > Quit bringing your offensive blame and guilt crap to comp.lang.lisp.
Once again, we have the fine example of Erik to teach us all. Thank you again, Erik, for not only telling us what consitutes appropriate behavior, but also modeling it so well. Your kindness and compassion are a model to us all, and we should all be very grateful that we have someone as pleasant as you to keep us on the straight and narrow.
> > > At some level every argument passing mechanism ever invented is "call by > > > value" because it consists of copying some bits from an arbitrary place > > > in the caller to some place that the callee knows to look for them.
> > This is not true.
> Yes it is.
> > In a call-by-reference language the bits that are passed to the > > callee are *not* a copy of the caller's bits but the address of the > > caller's bits.
> The caller either already has those bits stored explicitly in a register > or in the current stack frame, or else has those bits implicitly > available and regenerates them each time using something such as a > LEA/PEA (load/push effective address) instruction.
> Either way, they are the caller's bits and they are passed by copying > them into the callee.
> > In a call-by-name language there aren't even any bits in > > the caller. The caller passes a thunk to *compute* the bits if it > > becomes necessary.
> Exactly as I said in the following paragraph, which you snipped.
> "The only interesting question at the implementation (not conceptual) > level is: "*What* is it that is being passed by value?" The integer > itself? A reference to where the integer is stored? A reference to > some code that knows how to get and set the integer?"
Stop spreading falsehoods, will you? In both Lisp and C, an assignment to the variable that is the formal parameter of a function does not affect the caller. That's why it is called cbv and not cbr. Period.
Everything else is pointer- (aka reference-) semantics and has nothing to do with how parameters are passed.
> > > > > It's easiest if you think of *everything* as being pass-by-reference.
> > > > It may be "easiest", but it is also completely wrong.
> > > > Notice that "pass-by-value" (which is the only correct answer to the > > > > question) does not imply that the caller cannot change parts of a data > > > > structure. The whole question is *only* about how the formal > > > > parameter of the function (i.e., within the caller) is related to the > > > > actual argument given at the callsite.
> > > > Call-by-reference, otoh, would mean that in
> > > > (defun f (x) (setq x 2)) > > > > (defun g (y) (f y) y) > > > > (g 1)
> > > > the final answer from calling g would have to be 2.
> > > ?? No it would not.
> > > Here's the equivilent C code (with types assumed to be integers for > > > simplicity):
> > > #include <iostream.h>
> > > int* f(int *x){return x = new int(2);} > > > int* g(int *y){f(y); return y;}
> > > This prints "1", just as any Lisp does (CL, elisp, scheme, dylan).
> > FYI, this is C++, not C.
> Sure. Mostly because the C++ syntax for allocating and initializing a > heap object happens to be more convenient than in C.
> > Anyway, you see the same effect as in Lisp because your code uses > > CALL-BY-VALUE, just like Lisp (and C) does!!
> I think you're devaluing the meaning of the term "call by value". At > some level every argument passing mechanism ever invented is "call by > value" because it consists of copying some bits from an arbitrary place > in the caller to some place that the callee knows to look for them.
Sure. Bits get copied. BUT THAT IS NOT WHAT THE TERM IS ABOUT! For the last time: cbv (or cbr, or cbn) describes the semantic relationship between the *name* that is the formal parameter and the *expression* that is the actual argument.
Gabe Garza <g_ga...@ix.netcom.com> writes: > you can return multiple values by returning multiple values > instead of having an "argument" be a return value, etc.
I see two benefits in returning multiple values via parameters as in C, compared to multiple values in Lisp:
1. The names of the parameters can describe the values. In Lisp, you can get a similar effect with a documentation string.
2. By giving a C function a null pointer as a parameter, you can instruct it not to store the corresponding value. (The function must explicitly support this; strtol() does.) The function may even be able to completely avoid computing the value. I am not aware of such an idiom in Lisp.
I think I would prefer crossing these features with keyword arguments, so that new return values could be added to functions without affecting existing callers. A function call would specify which values it wants. Functions would normally provide all available values and Lisp would discard the unused ones, but there would also be a way for functions to check which values are needed and compute only those.
Has this already been implemented in some language? If so, how does the syntax look?
On Fri, 3 May 2002 18:59:44 GMT, Kent M Pitman <pit...@world.std.com> wrote:
[about call by value, call by reference, call by name, etc.]
> 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,
I have a data point that seems to confirm this. At least a few years ago, computer science students at the University of Milano, Italy, were explicitly taught argument passing semantics[+] only in an optional[*], 3rd year class. It was one of those comparative programming languages class. Maybe Marco can provide some more information.
> 2. By giving a C function a null pointer as a parameter, you can > instruct it not to store the corresponding value. (The > function must explicitly support this; strtol() does.) > The function may even be able to completely avoid computing > the value. I am not aware of such an idiom in Lisp.
Functions in Lisp often take NIL or some other placeholder like :DONT-STORE in place of another argument in order to suppress a behavior.
I've also written functions that do the conceptual equivalent of
> I think I would prefer crossing these features with keyword > arguments, so that new return values could be added to functions > without affecting existing callers. A function call would > specify which values it wants. Functions would normally provide > all available values and Lisp would discard the unused ones, but > there would also be a way for functions to check which values are > needed and compute only those.
I bet the CMU compiler or one very like it can already do this with clever inlining under block compilation.
> Has this already been implemented in some language? > If so, how does the syntax look?
IMO, it should look just like the syntax looks now.
Just because implementations don't do all these things doesn't mean the language precludes these things from happening.
To make this question really fair, though, why not turn it around the other way and offer a piece of code that does something real that you want to see optimized, and then ask how compilers could better treat it and/or how you could reorganize things to make it better for compilers...? You're putting the burden on people who don't necessarily agree that the deficiency is as great as you say to both come up with examples of your problem and offer solutions. That's a lot to ask.
In article <fosn59mdgp....@blume-pcmh.research.bell-labs.com>, Matthias Blume <matth...@shimizu-blume.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.
(defparameter *x* (cons 1 2))
(defun f (y) (prog1 (eq y *x*) (setf (car y) 'something-else)))
(f *x*) --> T *x* --> (SOMETHING-ELSE . 2)
> The assignment to y will not affect x.
Of course not.
> > > PARAMETER PASSING IN LISP IS CALL-BY-VALUE.
> > Whatever. but Harbison & Steele clearly indicates in the above > > that call-by-value implies parameter copying.
> Indeed.
That contradicts what you wrote earlier:
> In C, pass-by-value implies that a copy is made of the value > passed,
Nonsense!! In C, as in Lisp, no copy is made.
good night.
-- "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 <sfwy9f1yuel....@shell01.TheWorld.com>, Kent M Pitman <pit...@world.std.com> wrote:
> 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.
> At the surface level, it is pointless and a distraction to teach it this > way.
I'm not sure what 'the pointer being copied' implies, but I just take your word [that it's pointless] for now. Maybe I'll go deeper and study this lengthy thread later though.
good night, 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>
* Kalle Olavi Niemitalo | I think I would prefer crossing these features with keyword arguments, so | that new return values could be added to functions without affecting | existing callers. A function call would specify which values it wants. | Functions would normally provide all available values and Lisp would | discard the unused ones, but there would also be a way for functions to | check which values are needed and compute only those.
Please note that Common Lisp is _much_ more descriptive than one might think from a C-like point of view. If you ask for the nth value, that could conceivably be communicated in the call because the call contains enough context to know, and so too if non-primary values are ignored, or even all values, it may cause a different call. If Common Lisp were compiled to a fairly standard CLVM and that again was compiled as more knowledge of the actual function calling pattern emerged, as in Sun's HotSpot for Java we could see that kind of stuff dynamically evolve and not be prepared for by the compiler into static machine code. -- 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.
* k...@ma.ccom (Takehiko Abe) | > > > PARAMETER PASSING IN LISP IS CALL-BY-VALUE. | > > | > > Whatever. but Harbison & Steele clearly indicates in the above | > > that call-by-value implies parameter copying. | > | > Indeed. | | That contradicts what you wrote earlier: | | > In C, pass-by-value implies that a copy is made of the value | > passed, | | Nonsense!! In C, as in Lisp, no copy is made. | | good night.
Look, guys, am I the only one here with a computer science education? (Besides Matthias Blume, obviously.) I have no idea how people get so screwd up -- if I had, I would make a comet carreer in psychiatry from watching all the nutjobs on USENET for so many years -- but call by value or reference or name refers to the information passed from the caller to the callee about how the arguments (actual parameters) to a function were specified. Let me take the standard three, again:
1 Call by value -- no information is passed from the caller to the callee about the origin of the argument, only its value is available. So when the formal parameter is used, it refers to a local binding of that value.
2 Call by reference -- information is passed that makes the callee to reference the actual argument, to which the formal parameter refers, so when the formal parameter is used, it indirectly refers to the caller's binding of that value.
3 Call by name -- information is passed that makes the actual argument as it was specified in the call available to the caller, including any bindings that an expression closes over, such that using the formal argument (acts as if the system) evaluates the expression each time.
This call-by-foo things is _so_ not about what the values of arguments might be. This is _only_ about how much the callee gets to know about the arguments it receives. I marvel at the lack of education or other exposure to these terms in the literature that could have produced such a horrible confusion. This is an extremely clear-cut differentiation of argument passing semantics that leaves no room for confusion. If you cannot access the _binding_ that was used as an actual argument in the callee, you do _not_ have call-by- reference semantics regardless of how much you may modify the contents of any composite object you are passed. -- 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.
And of course, you could always wrap this up in a macro to make it a little less awkward:
(named-value-bind ((x foo 1) (y bar) (z baz 3)) (values :foo 3 :bar 4 :bling "bling") (list x y z)) => (3 4 3)
[...]
> > I think I would prefer crossing these features with keyword > > arguments, so that new return values could be added to functions > > without affecting existing callers. A function call would > > specify which values it wants. Functions would normally provide > > all available values and Lisp would discard the unused ones, but > > there would also be a way for functions to check which values are > > needed and compute only those.
> I bet the CMU compiler or one very like it can already do this with > clever inlining under block compilation.
In fact, it does. This is something that it really seems best to leave to compilers, because it shouldn't be too hard for them to produce code that only computes the used values, and then the programmer never has to even think about this.
This is CMUCL 18c, Solaris/SPARC. The type and optimize declarations are to minimize the code produced, so you can see what's happening:
* (compile (defun foo (num num-vector) ;; this would be a nice time to be able to say ;; (optimize (ext:disassembly-readability 3)), heh (declare (optimize (speed 3) (safety 0)) (fixnum num) (type (simple-array fixnum) num-vector)) (flet ((worker () (dovector (n num-vector) (when (eql num n) (return-from worker (values n (evenp n))))))) (multiple-value-bind (primary secondary) (worker) (values primary secondary))))) Compiling LAMBDA (NUM NUM-VECTOR): Compiling Top-Level Form:
> > Has this already been implemented in some language? > > If so, how does the syntax look?
> IMO, it should look just like the syntax looks now.
Well, as it is, we don't have a nice way to use named values, but it's a simple macro away. And we do have the ability to compute only the values used already.
> Just because implementations don't do all these things doesn't mean the > language precludes these things from happening.
And actually, I think the language helps in this case. Because of the way you get to multiple values (calling a function), a combination of inlining and eliminating unused branches -- optimizations that are already going to be in most compilers, I'd think -- will do this without the compiler writer having to have thought about it explicitly.
> To make this question really fair, though, why not turn it around the > other way and offer a piece of code that does something real that you > want to see optimized, and then ask how compilers could better treat it > and/or how you could reorganize things to make it better for compilers...? > You're putting the burden on people who don't necessarily agree that the > deficiency is as great as you say to both come up with examples of your > problem and offer solutions. That's a lot to ask.
If it wasn't a lazy Saturday, I'd agree :)
-- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----'
> The phrase CALL-BY-VALUE depends on the meaning of VALUE in the programming > language being talked about. > In particular, what things in the language are VALUES and which are not.
> When we talk about CALL-BY-VALUE in C here the _values_ are the things that > are values in C. > When we talk about CALL-BY-VALUE in Lisp here the _values_ are the things > that are values in Lisp.
> i.e. the values being talked about in the aboves phrases are referring to > sets with different contents.
> While we might say that both C and Lisp are both CALL-BY-VALUE, if we wish > to explain to someone > what this phrase implies, then we have to describe the things which are a > values in one language and not > in the other (e.g. structures).
> Only someone who has a good understanding of both C and Lisp is going to > appreciated what the phrase > "both C and Lisp are both CALL-BY-VALUE" implies, and for them it is > redundant information.
I have understanding of C, but not much of Lisp. I still do understand what it means for both of them. So I am saying I agree with Matthias Blume here.
Java only have pass by value, but it does have references _which are passed by value_.
If a language have references, that does not imply that it has pass by reference semantics.
I find this so trivial I am amazed that apparently experienced programmers does not understand this.
> > you can return multiple values by returning multiple values > > instead of having an "argument" be a return value, etc.
> I see two benefits in returning multiple values via parameters as > in C, compared to multiple values in Lisp:
> 1. The names of the parameters can describe the values. In Lisp, > you can get a similar effect with a documentation string.
> 2. By giving a C function a null pointer as a parameter, you can > instruct it not to store the corresponding value. (The > function must explicitly support this; strtol() does.) > The function may even be able to completely avoid computing > the value. I am not aware of such an idiom in Lisp.
> I think I would prefer crossing these features with keyword > arguments, so that new return values could be added to functions > without affecting existing callers. A function call would > specify which values it wants. Functions would normally provide > all available values and Lisp would discard the unused ones, but > there would also be a way for functions to check which values are > needed and compute only those.
> Has this already been implemented in some language? > If so, how does the syntax look?
Sort of like this (this version always computes all the values, but you could hack it):
