This is the
talk page for discussing improvements to the
Evaluation strategy article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||
|
I've removed the following paragraph from the article:
Firstly, it's not clear what purpose this is supposed to serve. I don't see anything in what precedes it that might be taken to imply that evaluation is left-to-right. If this is considered an important point, it could be made in just two or three words by adding to the previous paragraph a statement that the order of evaluation may vary.
Secondly, it's partly unsourced and partly inaccurate. Unsourced: while it seems likely that "most" call-by-value languages evaluate left-to-right, it's not a claim we can make without providing evidence. And inaccurate: OCaml uses call-by-reference, with the exception that immutable int
values are encoded as nonaligned pointers and can therefore be passed by value.
— Haeleth Talk 14:02, 7 February 2006 (UTC)
The purpose of the paragraph is to inform the reader that call-by-value evaluation is not one particular strategy, but rather a family of strategies.
OCaml uses call-by-value, just like any other ML. If you want to pass a reference into a function, you pass an explicit reference by value, which brings me to another point.
Your removal of C++ bias in the article is appreciated; however, you've introduced some factual inaccuracies – for example, a pointer is not the same as a reference, and while many functional languages represent large heap values as boxed pointers, they are semantically call-by-value becasue the values pointed to do not change. We're not talking about calling conventions, we're talking about evaluation strategies. -- bmills 14:49, 7 February 2006 (UTC)
Clem Baker-Finch is my Comp Lecturer! Go Clem! (he's a funny guy) 61.9.204.168 04:12, 5 June 2006 (UTC)
The article currently says
Um, I'm fairly certain that call-by-value-result does not involve a reference, but instead copies the value in and out (ideally in registers, but compilers using a caller-restores-stack protocol can copy results off the stack). I know the Ada 83 spec had special rules for the interaction of in out parameters and exceptions to allow implementors to use call-by-reference for large types but require use of call-by-value for small types.
Is not a correction needed here? Cheers, CWC (talk) 19:19, 23 August 2006 (UTC)
Jet SQL uses a version of call-by-name/call by need. when used as arguments for a column, functions with no dynamic arguments are memoized, functions with dynamic arguments are call-by-name, which means that they are called multiple times. there is no protection against side affects, so a function may return different values for the same arguments. 218.214.148.10 00:10, 27 September 2006 (UTC)
According to the current draft for r6rs, scheme uses call-by-value, but not in contrast to call-by-reference, but in contrast to lazy evaluation. It also says that Scheme always uses call-by-reference. So in the terminology of this article it uses call-by-reference, not call-by-value. -- MarSch 16:59, 20 October 2006 (UTC)
Glug... there are multiple competing definitions of call-by-reference. I claim that the most satisfying one is the one that appears in EOPL: "When an operand is a variable and the called procedure assigns to the corresponding formal parameter, is this visible to the caller as a change in the binding of its variable?" Call-by value: no. Call-by-reference: yes. That is, call-by-value vs. call-by-reference has to do with the behavior of assignment to bindings, and not to assignment within structures. The text provides this example:
let p = proc (x) x := 5 in let a = 3; b = 4 in begin p(a); p(b); +(a, b) end
Using call-by-value, this produces 7. Using call-by-reference, this produces 10. This question is entirely orthogonal to whether or not changes to passed values (e.g., objects) are visible in the calling procedure. Does anyone mind if I take a crack at a rewrite of this section? Clements ( talk) 17:03, 31 October 2008 (UTC)
Isn't there an important distinction between concepts like normal and applicative order reduction and concepts like call by reference, call by value and call by name? The former concern the rule(s) used for reducing an evaluation to a final result, while the latter concern how parameters are passed to a function. There's a clear relation, a particular evaluation strategy may restrict the kinds of parameter passing mechanisms that can be used; but the basic concepets are different. Abcarter 14:33, 14 December 2006 (UTC)
I agree with Abcarter. The section seems to confuse the concepts a bit. Applicative order languages (and strict evaluation) is usually used to refer to languages that have call-by-value semantics, or one of the other strict semantics. Likewise, normal order is used to refer to languages with call-by-name or call-by-need semantics. I have never seen the distinction (comparison) made in the article between applicative order and call-by-value. I believe it is incorrect for the reason described above. If not, explicit references to the definitions would be appreciated. —Preceding unsigned comment added by 85.80.230.242 ( talk) 18:30, 6 October 2008 (UTC)
In the reading that I've done, strict and eager are pretty much equivalent terms. I could easily be wrong, but I'm certainly confused why "Church encoding" is the determining fact here. The issue with non-strict and lazy is not as simple, but in most of the literature I've read lazy is a type of non-strict evaluation where every argument is never evaluated more than once. But the same confusion remains why Church encoding is particularly relevant here. Could someone please provide a citation. Abcarter 01:55, 19 December 2006 (UTC)
I deleted the sentence concerning conditional statements in the section on non-strict evaluation. As the definition itself mentions, non-strict evaluation is about how arguments to a function are processed. There is a fundamental distinction here: expressions can be passed to an argument, a command or statement cannot. Abcarter 02:10, 19 December 2006 (UTC)
IF <boolean list> THEN <list expression> ELSE <list expression>
if(ptr != NULL && *ptr != 0)
in C or C++, where &&
's short-circuiting effect prevents ptr
from being dereferenced if it's the null pointer), but this isn't really the primary reason for the short-circuiting: the primary reason is to avoid needless computation when the ultimate value of a boolean expression is already known. (Well, in modern languages it can be hard to tell which is the primary reason, as the two are rather intertwined now, but I think a convincing argument can be made that laziness was the original reason, at least.) By contrast, the short-circuiting of a language's conditional operator is absolutely fundamental to its functioning, at least in a language where expressions can have side effects (which so far as I know is the case in every language that has a conditional operator; there are languages where really only complete statements have side effects, but I don't know of any that are of that type and that nonetheless have conditional operators that can be used in expressions). I hope that explanation makes some sense … —
Ruakh
TALK
08:04, 31 December 2006 (UTC)if true then print "foo" else print "bar"
printed something other than simply foo
.fun fact(x : int) : int = if x <= 1 then 1 else x * fact(x - 1)
produced a function that never terminated, because its recursive call was always evaluated, even when not needed.Perhaps I'm ignorant... but when I clicked the link to here from the Expression page, and read the first sentence ... An evaluation strategy (or reduction strategy) for a programming language is a set of (usually deterministic) rules for defining the evaluation of expressions under β-reduction. ... I thought I found the page I was looking for. But there's nothing about expression evaluation, in general. Does anyone else see the need for an explanation of evaluation strategy relating to operators, not just the various forms and issues of function calls? Maybe the research just has not been done yet. Comments? AgentFriday 02:46, 28 December 2006 (UTC)
I suppose as this is Evaluation strategy and not procedure calling method that question makes sense, but even the latter becomes important in some case. For languages that allow for aggregate (structures, arrays, or combinations of the two) expressions, evaluation strategy is still important. PL/I, which has allowed for array and structure expressions since its origins in the early 1960's, requires that changes take effect immediately, similar to call by reference. Fortran, since array expressions were added in 1990, requires that the whole right hand side of an assignment be evaluated before the left side is changed (at least in the cases where it matters). This could be considered similar to call by value. Gah4 ( talk) 08:40, 13 June 2017 (UTC)
Could anyone add some small picture that demonstrates the interactions between function and calling function? I am no expert in programming languages and for me it would just be helpfull to see what symbols can be passed from one context into another.
217.10.60.85 ( talk) 10:30, 21 November 2007 (UTC)
I have removed the following sentence from the section on call-by-reference:
As noted elsewhere on the page, Java uses "call-by-value where the value is a reference" or call-by-sharing. This may sometimes give the same result as call-by-reference, but that's a totally different thing to "display[ing] call-by-reference semantics". HenryAyoola ( talk) 11:57, 6 October 2009 (UTC)
In your Article you have: "A few languages, such as C++, PHP, Visual Basic .NET, C# and REALbasic, default to call-by-value"
http://msdn.microsoft.com/en-us/library/ee478101%28v=vs.84%29.aspx : "In a Sub or Function declaration, each parameter can be specified as ByRef or ByVal. If neither is specified, the default is ByRef."
but i'll allow that very few VB programmers can state this with certainty -sigh- — Preceding unsigned comment added by 50.159.60.209 ( talk) 21:54, 22 December 2013 (UTC)
There should be no distinct paragraph for call by address, since this article is about language semantics, not programming techniques. I insist that it should be merged back to call-by-reference. The term "call by address" just should be mentioned, and that's all. Moreover, there were made two shortcomings. First, call by address is memory-unsafe only in C, but not in ML - so this is not common. Second, the code sample in C was more informative, showing three cases of using pointers in C, wich is important when comparing call-by-value with call-by-address. Arachnelis ( talk) 10:03, 1 June 2014 (UTC)
Ok Kelvin1980 ( talk) 04:10, 5 November 2017 (UTC)
Citing the section Evaluation strategy#Call by sharing:
This needs some clarification without going to deeply into the idiosyncrasies of Python. What is meant is that each object has an "identity", typically represented as the bit pattern of a pointer to the object, and a function can find out this identity and act accordingly. Should we just rephrase this as
and leave the issue of identity aside?
The section also has one more Python-specific part, where the assignment to a variable is described (it previously claimed a "new variable" was created, which strictly speaking is not what happens). This is really language-specific. One can imagine a language where assignment is an overloadable in-place operation, (like in C++ with operator=
, and like some assignments in Python with __setitem__
), in which case a let
-style construct is needed to express the function:
# pseudo-Python
def f(l):
l = 1
def g(l):
let l = 1, 2, 3
m = []
f(m)
# m is now [1]
g(m)
# m is still [1]
QVVERTYVS ( hm?) 12:50, 4 June 2014 (UTC)
Is JavaScript call-by-value or call-by-reference? specifically calls out this article:
The Wikipedia entry for Evaluation Strategy is long, confusing and sometimes contradictory because the various terms have been inconsistently applied to languages throughout the years.
Seem like the article has a relatively clear explanation but I should find a couple more weighty sources. II | ( t - c) 07:58, 29 May 2016 (UTC)
As long as the callee in a call by value system doesn't modify a passed reference, the effect is the same as call by reference. But in languages like C and Java, the callee is allowed to modify a reference, such that it refers to something else. In this case, passing a reference by value is the right explanation. Gah4 ( talk) 08:51, 13 June 2017 (UTC)
But I'm willing to be disproved. Right now, the article says "Although this term has widespread usage in the Python community, identical semantics in other languages such as Java and Visual Basic are often described as call by value, where the value is implied to be a reference to the object.[citation needed]". Except even the Python tutorial avoids using "call-by-sharing" as a term; it describes the language as "call by value" with a footnote that indicates that "call by object reference" might be a more precise term. It doesn't use "call by sharing" at all. — ShadowRanger ( talk| stalk) 02:11, 23 August 2016 (UTC)
Since remote evaluation is defined as the server executing code from the client, and client-side scripting is defined as the opposite, isn't client-side scripting an evaluation strategy too? -- 146.140.210.15 ( talk) 16:51, 7 February 2017 (UTC)
There is no section for call by descriptor, where a descriptor, sometimes called a dope vector, is passed, usually by address, to the called routine. This is used by PL/I for passing strings, arrays, and structures, by Fortran 77 for passing strings, and by Fortran 90 and later for assumed shape arrays. The descriptor contains array bounds, and an address (or two) for use by the callee to access the data. Also, VAX allows for %val, %ref, and %descr to override the default calling convention, especially useful with mixed language programming. Gah4 ( talk) 08:59, 13 June 2017 (UTC)
Evaluation strategy#Call by need Claims Call by need is a memoized version of call by name. However, Lazy evaluation has different semantics from call by name. A typical examples is a routine that uses Simpson's rule to do integration, declaring the integration variable and integrand as call by name. The algorithm depends on evaluating the integrand separately for each value set into the integration variable. Use lazy evaluation and you get the wrong results. Shmuel (Seymour J.) Metz Username:Chatul ( talk) 22:20, 9 February 2018 (UTC)
The bits that refer to Fortran are largely incorrect and need tidying up. In this case, the evaluation strategy *is* actually a function of the implementation; the language does not require call by reference. — Preceding unsigned comment added by 84.92.84.4 ( talk) 11:23, 18 February 2018 (UTC)
I find the organization of the "call by sharing" / "call by value where the value is a reference" not optimal:
Already before the section "call by sharing" it is referred to under "implicit limitations" of "call by value". Moreover, there it is (correctly) stated that this is frequently referred to as "call by value where the value is a reference", but this description is missing under "call by sharing".
Also, the concept is not even explained under "call by sharing" and only vaguely under "implicit limitations".
However, under "Call by sharing" it is stated (arguably also correctly but confusingly) that in the Java community the same concept is called "call by value".
Putting this together, there are two places for the same concept in the article with a reference from the first to the second but not the other way around and various conflicting names for the same concept.
My suggestions are as follows:
- Shorten "implicit limitations" to a small comment that often only pointers are passed by value and that this will be explained below under "call by sharing"
- Explain there that "call by sharing" is call by value where the value is a reference (= pointer).
- Also explain that intuitively one does not have to think about pointers. Rather one can think about variables directly referring to objects or as names of objects. (Actually this seems to be the cultural difference between the Java and the python communities: In the Java community people still have pointers in mind (coming from C++) whereas in python people only have objects in mind. Java people: The values of variables (for non-primitive types) are pointers pointing to objects. Python people: "Names refer to objects", as stated in the documentation [1]. If one thinks about what the second really means, on arrives at the first, but still the intuition is different.)
In addition I want to point out a minor statement in the article which is actually nonsensical:
"It [call by sharing] It is used by languages such as Python,[7] Iota,[8] Java (for object references), Ruby, JavaScript, Scheme, OCaml, AppleScript, and many others."
With the comment on Java one arrives at this nonsensical statement: In Java call by sharing is used for object references, that is object references are passed via references (to the object references). In fact, the references are passed by value.
A corrected statement is "Java (for non-primitive data types)".
Claus from Leipzig ( talk) 19:51, 12 August 2018 (UTC)
Should there be a section discussing the use of global variables, such as Fortran COMMON, or external structures in other languages, to pass data to/from called routines? My first thought was that this could be call by sharing, but that seems to be something else. Gah4 ( talk) 20:20, 7 May 2019 (UTC)
Variables are not called, but they are passed to a sub-routine or function. So the proper wording is "pass by ...", but not "call by ...". — Preceding unsigned comment added by 89.12.24.157 ( talk) 06:57, 29 April 2020 (UTC)
It'd be nice to include some information about lenient evaluation, a non-strict evalutation strategy in-between laziness and strictness used by both Id (programming language) and the parallel Haskell project. Some relevant sources are the Id reference manual and any of the references in How much non-strictness do lenient programs require?.
Note that Fortran allows for either call by reference or call by value result. So, in fact, it is specific to the implementation. That is true for the ANSI standards from Fortran 66 to the most recent version. Fortran IV is mostly close to ANSI Fortran 66, though might be different for different machines. The OS/360 Fortran IV compilers pass arrays by reference and scalars by value result. Gah4 ( talk) 01:57, 8 January 2022 (UTC)
My edit adding CBPV was reverted saying no reliable source says it's a, evaluation strategy. But the abstract of the article that defines CBPV clearly puts CBPV in the same category as CBV and CBN:
Call-by-push-value is a new paradigm that subsumes the call-by-name and call-by-value paradigms
— Paul Blain Levy, Call-by-Push-Value: A Subsuming Paradigm.
Nowhere man ( talk) 05:47, 9 April 2024 (UTC)
This is the
talk page for discussing improvements to the
Evaluation strategy article. This is not a forum for general discussion of the article's subject. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||
|
I've removed the following paragraph from the article:
Firstly, it's not clear what purpose this is supposed to serve. I don't see anything in what precedes it that might be taken to imply that evaluation is left-to-right. If this is considered an important point, it could be made in just two or three words by adding to the previous paragraph a statement that the order of evaluation may vary.
Secondly, it's partly unsourced and partly inaccurate. Unsourced: while it seems likely that "most" call-by-value languages evaluate left-to-right, it's not a claim we can make without providing evidence. And inaccurate: OCaml uses call-by-reference, with the exception that immutable int
values are encoded as nonaligned pointers and can therefore be passed by value.
— Haeleth Talk 14:02, 7 February 2006 (UTC)
The purpose of the paragraph is to inform the reader that call-by-value evaluation is not one particular strategy, but rather a family of strategies.
OCaml uses call-by-value, just like any other ML. If you want to pass a reference into a function, you pass an explicit reference by value, which brings me to another point.
Your removal of C++ bias in the article is appreciated; however, you've introduced some factual inaccuracies – for example, a pointer is not the same as a reference, and while many functional languages represent large heap values as boxed pointers, they are semantically call-by-value becasue the values pointed to do not change. We're not talking about calling conventions, we're talking about evaluation strategies. -- bmills 14:49, 7 February 2006 (UTC)
Clem Baker-Finch is my Comp Lecturer! Go Clem! (he's a funny guy) 61.9.204.168 04:12, 5 June 2006 (UTC)
The article currently says
Um, I'm fairly certain that call-by-value-result does not involve a reference, but instead copies the value in and out (ideally in registers, but compilers using a caller-restores-stack protocol can copy results off the stack). I know the Ada 83 spec had special rules for the interaction of in out parameters and exceptions to allow implementors to use call-by-reference for large types but require use of call-by-value for small types.
Is not a correction needed here? Cheers, CWC (talk) 19:19, 23 August 2006 (UTC)
Jet SQL uses a version of call-by-name/call by need. when used as arguments for a column, functions with no dynamic arguments are memoized, functions with dynamic arguments are call-by-name, which means that they are called multiple times. there is no protection against side affects, so a function may return different values for the same arguments. 218.214.148.10 00:10, 27 September 2006 (UTC)
According to the current draft for r6rs, scheme uses call-by-value, but not in contrast to call-by-reference, but in contrast to lazy evaluation. It also says that Scheme always uses call-by-reference. So in the terminology of this article it uses call-by-reference, not call-by-value. -- MarSch 16:59, 20 October 2006 (UTC)
Glug... there are multiple competing definitions of call-by-reference. I claim that the most satisfying one is the one that appears in EOPL: "When an operand is a variable and the called procedure assigns to the corresponding formal parameter, is this visible to the caller as a change in the binding of its variable?" Call-by value: no. Call-by-reference: yes. That is, call-by-value vs. call-by-reference has to do with the behavior of assignment to bindings, and not to assignment within structures. The text provides this example:
let p = proc (x) x := 5 in let a = 3; b = 4 in begin p(a); p(b); +(a, b) end
Using call-by-value, this produces 7. Using call-by-reference, this produces 10. This question is entirely orthogonal to whether or not changes to passed values (e.g., objects) are visible in the calling procedure. Does anyone mind if I take a crack at a rewrite of this section? Clements ( talk) 17:03, 31 October 2008 (UTC)
Isn't there an important distinction between concepts like normal and applicative order reduction and concepts like call by reference, call by value and call by name? The former concern the rule(s) used for reducing an evaluation to a final result, while the latter concern how parameters are passed to a function. There's a clear relation, a particular evaluation strategy may restrict the kinds of parameter passing mechanisms that can be used; but the basic concepets are different. Abcarter 14:33, 14 December 2006 (UTC)
I agree with Abcarter. The section seems to confuse the concepts a bit. Applicative order languages (and strict evaluation) is usually used to refer to languages that have call-by-value semantics, or one of the other strict semantics. Likewise, normal order is used to refer to languages with call-by-name or call-by-need semantics. I have never seen the distinction (comparison) made in the article between applicative order and call-by-value. I believe it is incorrect for the reason described above. If not, explicit references to the definitions would be appreciated. —Preceding unsigned comment added by 85.80.230.242 ( talk) 18:30, 6 October 2008 (UTC)
In the reading that I've done, strict and eager are pretty much equivalent terms. I could easily be wrong, but I'm certainly confused why "Church encoding" is the determining fact here. The issue with non-strict and lazy is not as simple, but in most of the literature I've read lazy is a type of non-strict evaluation where every argument is never evaluated more than once. But the same confusion remains why Church encoding is particularly relevant here. Could someone please provide a citation. Abcarter 01:55, 19 December 2006 (UTC)
I deleted the sentence concerning conditional statements in the section on non-strict evaluation. As the definition itself mentions, non-strict evaluation is about how arguments to a function are processed. There is a fundamental distinction here: expressions can be passed to an argument, a command or statement cannot. Abcarter 02:10, 19 December 2006 (UTC)
IF <boolean list> THEN <list expression> ELSE <list expression>
if(ptr != NULL && *ptr != 0)
in C or C++, where &&
's short-circuiting effect prevents ptr
from being dereferenced if it's the null pointer), but this isn't really the primary reason for the short-circuiting: the primary reason is to avoid needless computation when the ultimate value of a boolean expression is already known. (Well, in modern languages it can be hard to tell which is the primary reason, as the two are rather intertwined now, but I think a convincing argument can be made that laziness was the original reason, at least.) By contrast, the short-circuiting of a language's conditional operator is absolutely fundamental to its functioning, at least in a language where expressions can have side effects (which so far as I know is the case in every language that has a conditional operator; there are languages where really only complete statements have side effects, but I don't know of any that are of that type and that nonetheless have conditional operators that can be used in expressions). I hope that explanation makes some sense … —
Ruakh
TALK
08:04, 31 December 2006 (UTC)if true then print "foo" else print "bar"
printed something other than simply foo
.fun fact(x : int) : int = if x <= 1 then 1 else x * fact(x - 1)
produced a function that never terminated, because its recursive call was always evaluated, even when not needed.Perhaps I'm ignorant... but when I clicked the link to here from the Expression page, and read the first sentence ... An evaluation strategy (or reduction strategy) for a programming language is a set of (usually deterministic) rules for defining the evaluation of expressions under β-reduction. ... I thought I found the page I was looking for. But there's nothing about expression evaluation, in general. Does anyone else see the need for an explanation of evaluation strategy relating to operators, not just the various forms and issues of function calls? Maybe the research just has not been done yet. Comments? AgentFriday 02:46, 28 December 2006 (UTC)
I suppose as this is Evaluation strategy and not procedure calling method that question makes sense, but even the latter becomes important in some case. For languages that allow for aggregate (structures, arrays, or combinations of the two) expressions, evaluation strategy is still important. PL/I, which has allowed for array and structure expressions since its origins in the early 1960's, requires that changes take effect immediately, similar to call by reference. Fortran, since array expressions were added in 1990, requires that the whole right hand side of an assignment be evaluated before the left side is changed (at least in the cases where it matters). This could be considered similar to call by value. Gah4 ( talk) 08:40, 13 June 2017 (UTC)
Could anyone add some small picture that demonstrates the interactions between function and calling function? I am no expert in programming languages and for me it would just be helpfull to see what symbols can be passed from one context into another.
217.10.60.85 ( talk) 10:30, 21 November 2007 (UTC)
I have removed the following sentence from the section on call-by-reference:
As noted elsewhere on the page, Java uses "call-by-value where the value is a reference" or call-by-sharing. This may sometimes give the same result as call-by-reference, but that's a totally different thing to "display[ing] call-by-reference semantics". HenryAyoola ( talk) 11:57, 6 October 2009 (UTC)
In your Article you have: "A few languages, such as C++, PHP, Visual Basic .NET, C# and REALbasic, default to call-by-value"
http://msdn.microsoft.com/en-us/library/ee478101%28v=vs.84%29.aspx : "In a Sub or Function declaration, each parameter can be specified as ByRef or ByVal. If neither is specified, the default is ByRef."
but i'll allow that very few VB programmers can state this with certainty -sigh- — Preceding unsigned comment added by 50.159.60.209 ( talk) 21:54, 22 December 2013 (UTC)
There should be no distinct paragraph for call by address, since this article is about language semantics, not programming techniques. I insist that it should be merged back to call-by-reference. The term "call by address" just should be mentioned, and that's all. Moreover, there were made two shortcomings. First, call by address is memory-unsafe only in C, but not in ML - so this is not common. Second, the code sample in C was more informative, showing three cases of using pointers in C, wich is important when comparing call-by-value with call-by-address. Arachnelis ( talk) 10:03, 1 June 2014 (UTC)
Ok Kelvin1980 ( talk) 04:10, 5 November 2017 (UTC)
Citing the section Evaluation strategy#Call by sharing:
This needs some clarification without going to deeply into the idiosyncrasies of Python. What is meant is that each object has an "identity", typically represented as the bit pattern of a pointer to the object, and a function can find out this identity and act accordingly. Should we just rephrase this as
and leave the issue of identity aside?
The section also has one more Python-specific part, where the assignment to a variable is described (it previously claimed a "new variable" was created, which strictly speaking is not what happens). This is really language-specific. One can imagine a language where assignment is an overloadable in-place operation, (like in C++ with operator=
, and like some assignments in Python with __setitem__
), in which case a let
-style construct is needed to express the function:
# pseudo-Python
def f(l):
l = 1
def g(l):
let l = 1, 2, 3
m = []
f(m)
# m is now [1]
g(m)
# m is still [1]
QVVERTYVS ( hm?) 12:50, 4 June 2014 (UTC)
Is JavaScript call-by-value or call-by-reference? specifically calls out this article:
The Wikipedia entry for Evaluation Strategy is long, confusing and sometimes contradictory because the various terms have been inconsistently applied to languages throughout the years.
Seem like the article has a relatively clear explanation but I should find a couple more weighty sources. II | ( t - c) 07:58, 29 May 2016 (UTC)
As long as the callee in a call by value system doesn't modify a passed reference, the effect is the same as call by reference. But in languages like C and Java, the callee is allowed to modify a reference, such that it refers to something else. In this case, passing a reference by value is the right explanation. Gah4 ( talk) 08:51, 13 June 2017 (UTC)
But I'm willing to be disproved. Right now, the article says "Although this term has widespread usage in the Python community, identical semantics in other languages such as Java and Visual Basic are often described as call by value, where the value is implied to be a reference to the object.[citation needed]". Except even the Python tutorial avoids using "call-by-sharing" as a term; it describes the language as "call by value" with a footnote that indicates that "call by object reference" might be a more precise term. It doesn't use "call by sharing" at all. — ShadowRanger ( talk| stalk) 02:11, 23 August 2016 (UTC)
Since remote evaluation is defined as the server executing code from the client, and client-side scripting is defined as the opposite, isn't client-side scripting an evaluation strategy too? -- 146.140.210.15 ( talk) 16:51, 7 February 2017 (UTC)
There is no section for call by descriptor, where a descriptor, sometimes called a dope vector, is passed, usually by address, to the called routine. This is used by PL/I for passing strings, arrays, and structures, by Fortran 77 for passing strings, and by Fortran 90 and later for assumed shape arrays. The descriptor contains array bounds, and an address (or two) for use by the callee to access the data. Also, VAX allows for %val, %ref, and %descr to override the default calling convention, especially useful with mixed language programming. Gah4 ( talk) 08:59, 13 June 2017 (UTC)
Evaluation strategy#Call by need Claims Call by need is a memoized version of call by name. However, Lazy evaluation has different semantics from call by name. A typical examples is a routine that uses Simpson's rule to do integration, declaring the integration variable and integrand as call by name. The algorithm depends on evaluating the integrand separately for each value set into the integration variable. Use lazy evaluation and you get the wrong results. Shmuel (Seymour J.) Metz Username:Chatul ( talk) 22:20, 9 February 2018 (UTC)
The bits that refer to Fortran are largely incorrect and need tidying up. In this case, the evaluation strategy *is* actually a function of the implementation; the language does not require call by reference. — Preceding unsigned comment added by 84.92.84.4 ( talk) 11:23, 18 February 2018 (UTC)
I find the organization of the "call by sharing" / "call by value where the value is a reference" not optimal:
Already before the section "call by sharing" it is referred to under "implicit limitations" of "call by value". Moreover, there it is (correctly) stated that this is frequently referred to as "call by value where the value is a reference", but this description is missing under "call by sharing".
Also, the concept is not even explained under "call by sharing" and only vaguely under "implicit limitations".
However, under "Call by sharing" it is stated (arguably also correctly but confusingly) that in the Java community the same concept is called "call by value".
Putting this together, there are two places for the same concept in the article with a reference from the first to the second but not the other way around and various conflicting names for the same concept.
My suggestions are as follows:
- Shorten "implicit limitations" to a small comment that often only pointers are passed by value and that this will be explained below under "call by sharing"
- Explain there that "call by sharing" is call by value where the value is a reference (= pointer).
- Also explain that intuitively one does not have to think about pointers. Rather one can think about variables directly referring to objects or as names of objects. (Actually this seems to be the cultural difference between the Java and the python communities: In the Java community people still have pointers in mind (coming from C++) whereas in python people only have objects in mind. Java people: The values of variables (for non-primitive types) are pointers pointing to objects. Python people: "Names refer to objects", as stated in the documentation [1]. If one thinks about what the second really means, on arrives at the first, but still the intuition is different.)
In addition I want to point out a minor statement in the article which is actually nonsensical:
"It [call by sharing] It is used by languages such as Python,[7] Iota,[8] Java (for object references), Ruby, JavaScript, Scheme, OCaml, AppleScript, and many others."
With the comment on Java one arrives at this nonsensical statement: In Java call by sharing is used for object references, that is object references are passed via references (to the object references). In fact, the references are passed by value.
A corrected statement is "Java (for non-primitive data types)".
Claus from Leipzig ( talk) 19:51, 12 August 2018 (UTC)
Should there be a section discussing the use of global variables, such as Fortran COMMON, or external structures in other languages, to pass data to/from called routines? My first thought was that this could be call by sharing, but that seems to be something else. Gah4 ( talk) 20:20, 7 May 2019 (UTC)
Variables are not called, but they are passed to a sub-routine or function. So the proper wording is "pass by ...", but not "call by ...". — Preceding unsigned comment added by 89.12.24.157 ( talk) 06:57, 29 April 2020 (UTC)
It'd be nice to include some information about lenient evaluation, a non-strict evalutation strategy in-between laziness and strictness used by both Id (programming language) and the parallel Haskell project. Some relevant sources are the Id reference manual and any of the references in How much non-strictness do lenient programs require?.
Note that Fortran allows for either call by reference or call by value result. So, in fact, it is specific to the implementation. That is true for the ANSI standards from Fortran 66 to the most recent version. Fortran IV is mostly close to ANSI Fortran 66, though might be different for different machines. The OS/360 Fortran IV compilers pass arrays by reference and scalars by value result. Gah4 ( talk) 01:57, 8 January 2022 (UTC)
My edit adding CBPV was reverted saying no reliable source says it's a, evaluation strategy. But the abstract of the article that defines CBPV clearly puts CBPV in the same category as CBV and CBN:
Call-by-push-value is a new paradigm that subsumes the call-by-name and call-by-value paradigms
— Paul Blain Levy, Call-by-Push-Value: A Subsuming Paradigm.
Nowhere man ( talk) 05:47, 9 April 2024 (UTC)