Talk:Evaluation strategy

message: I've removed the following paragraph from the article:
: Note that call-by-value does not necessarily mean left-to-right evaluation.  While most programming languages that use call-by-value do evaluate function arguments left-to-right, some (such as OCaml) evaluate functions and their arguments right-to-left.
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)
thread_title:  Evaluation order 

message: 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)
thread_title:  call by name in SQL 

message: 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)
thread_title:  Strict/Eager and Non-strict/Lazy 

message: 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)
replies: text: Question, at the level that we are talking about is there a real difference between how a function is handled and how an operator is handled? Isn't a primitive operator simply a built-in function with perhaps a different syntax? Abcarter 17:38, 28 December 2006 (UTC)
replies: text: Two answers :)  1: Perhaps a majority of the visitors to this page are not thinking at, or expecting, such an academic discussion on expression evaluation.  I personally find the discussion interesting, but feel the page is lacking in coverage of infix notation, and strategies for resolving it.  2:  Yes, every operation in an expression can be written as a function call, and in fact that is more obvious as to order of evaluation.  However, given an expression in a standard programming language, you must still apply the rules of precedence and associativity first in order to know how to group the function calls.  ...  After some more searching, I found the page Common operator notation, which at least touches the surface of what I was expecting to find here.  Perhaps it would be beneficial for this page to have a link there.  It also may be that the link to here from Expression (and others) is inappropriate, or at least could use qualification.  I'll trust that the title is appropriate for the content, but the first paragraph makes several references to expressions, which in the classical sense (and even in the context in which they are referenced) are infix notation.  An evaluation strategy is also needed for this type of expression, but the article makes no reference to such or why it is not covered.  Looking over the articles that link to this one, about 1/3 seem to be from pages mentioning expression evaluation (with no hint of the function-specific discussion ahead), about 1/3 are links from function-related topics (appropriate), and the rest seem to be miscellaneous "see also" links, etc.  To me, there seems to be a disconnect.  Anyway, thanks for reading.  I thought some change was in order, but decided I was not qualified to jump in and make changes in this case.  Hope you can see my point. AgentFriday 00:56, 29 December 2006 (UTC)
replies: text: Surprisingly enough I think we're talking about two entirely different concepts. Just to confirm this I'm assuming that you are concerned with expressions like 2 + 5 * 3 and whether this evaluates to 2 + (5 * 3) = 17 or to (2 + 5) * 3 = 30. In particular you're concerned with rules or precedence. If so then my initial remark stands. Evaluation strategy as referred to in this entry is in fact a technical topic dealing with the semantics of a programming language. In this sense an expression is simply a syntactic construct that can be reduced to a data value. Don't get confused by the examples that happen to use infix notation. It's just easier and more clear to write 2 + 3 than add(2, 3), but at this level of discussion there is no conceptual difference, they're both just expressions. None of this is to say that you're concerns don't deserve it's own entry and it may well make sense to mark this distinction and provide a link. Abcarter 13:58, 29 December 2006 (UTC)
thread_title:  Content seems to cover only function calls... what about expressions in general? 

message: 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)
thread_title:  Scheme of memory context 

message: I have removed the following sentence from the section on call-by-reference:
:Some languages straddle both worlds; for example, Java is a call-by-value language, but since the results of most Java expressions are references to anonymous objects, it frequently displays call-by-reference semantics without the need for any explicit reference syntax.
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)
replies: text: I suppose, but as long as the reference variable isn't changed in the callee, the effect is the same as call by reference. Gah4 (talk) 08:43, 13 June 2017 (UTC)

text: IIRC Java passes primitives by copy of value, and objects by copy of reference. It can't pass objects, it always accesses them through references.Not quite pass-by-reference since the caller's variables are inaccessible, only its referenced object content.Not quite pass-by-sharing, since Java has copied primitives.Musaran (talk) 21:53, 15 November 2023 (UTC)
thread_title:  Java and call-by-reference 

message: 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)
replies: text: I don't know, but it seems that VB(A) is not Visual Basic.NET. http://msdn.microsoft.com/en-us/library/ddck1z30.aspx states "The default in Visual Basic is to pass arguments by value." Glrx (talk) 21:08, 26 December 2013 (UTC)
thread_title:  visual basic "VB(A)" is default call-by-reference according to microsoft 

message: 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)
replies: text: Insist seems a little strong, as in general it should be the consensus of editors, but otherwise agree that call by address should be an alternative name in the call by reference section. Gah4 (talk) 08:46, 13 June 2017 (UTC)
thread_title:  Call by address 

message: Citing the section Evaluation strategy#Call by sharing:
:For immutable objects, there is no real difference between call by sharing and call by value, except for the object identity.
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
:For immutable objects, there is typically no difference between call by sharing and call by value.
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)
thread_title:  Pythonisms in "call by sharing" section 

message: 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)
thread_title:  I don't think Python community favors "call-by-sharing" as a term 

message: 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)
thread_title:  Is client-side scripting an evaluation strategy? 

message: 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)
replies: text: After forgetting that I wrote the above, I am back here again.  The PL/I page indicates that it uses call by reference, but in many cases a descriptor (generally), or dope vector (what IBM documentation calls it) is used.  For one, this passes size and bounds information, but also it allows for non-contiguous data, such as array sections. Should we have a call by descriptor page?  Gah4 (talk) 20:24, 7 May 2019 (UTC)
replies: text: Seems a good idea. Those thinking that call-by-reference was the usual scheme in say Fortran, so usual as to not receive much mention, will (like me) be disconcerted by the results of passing certain types of array to a well-trusted routine such as a binary search and find that copy-in copy-out was happening, thus requiring an order N activity after which an order log(N) search was an irrelevant detail contributing to a thirty-fold reduction in speed as reward for the seemingly innocent improvement in readability afforded by combining a group of separate normal arrays into an aggregate array. This was because fancy modern syntax allow fancy parameter usage such as defining an aggregate STUFF(1:N) containing a component NAME and passing STUFF(1:N).NAME as the parameter for a search. But the routine expects contiguous array data, and so a copy of the elements of STUFF(1:N).NAME was made and passed. This is because the routine does not expect to receive a compound entity and so does not expect information such as would be provided by a "dope vector" containing not just the base address (as with pass by reference) but also the "stride" for the addressing of consecutive elements of the array, which is always one for normal contiguous arrays. Such added facilities enable conveniently flexible syntax and can avoid the need for copying array selections (say of a row or a column, or a block somewhere in the interior of a multi-dimensional array), but at the cost of the increased overhead in passing the additional information, plus of course the extra work required for each access to the complex item that has to employ all the added details. Another trick is to pass an allocatable but not-yet-allocated item to a procedure, which decides how big it should be, allocates it (say, it is to develop a sparse-matrix representation), and exits. The caller now has to know what has happened so as to access the item. The "dope vector" is thus itself passed by reference so that its contents may be altered for all to see. As features are added to languages, ever more subtle distinctions become supported as well. NickyMcLean (talk) 03:40, 8 May 2019 (UTC)
replies: text: Any disagreement on naming it call by descriptor?  I learned much of this reading the IBM documentation for the PL/I (F) compiler. One that I remember was that PL/I would pass an array element by reference, so you could call Fortran programs putting an array element in the argument list.  That didn't work for CHARACTER, which is always passed by descriptor. Gah4 (talk) 06:24, 8 May 2019 (UTC)
replies: text: Go ahead and add it, since it's a thing, you know your stuff, and have sources. But a section here should suffice, not a page. Musaran (talk) 22:09, 15 November 2023 (UTC)
replies: text: I disagree, I think these low-level details like dope vectors and so on are details of the calling convention, the evaluation strategy is still pass-by-reference. I think the right place to add it would be the PL/I page since it is mainly a PL/I internal implementation detail. Mathnerd314159 (talk) 16:56, 17 November 2023 (UTC)
thread_title:  call by descriptor 

message: 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)
replies: text: Yes, the difference in semantics is precisely that call by need memoizes the result, and thus only evaluates the argument once. Perhaps "version" is the wrong word; would you prefer "variant"? --Macrakis (talk) 22:41, 9 February 2018 (UTC)
thread_title:  Call by need is '''not''' a version of call by name  

message: 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)
replies: text: Even more, one implementation might use different ones in different cases. The OS/360 compilers pass scalars by value-result, as it is more efficient (in some cases) but arrays by reference.  In some cases, Fortran 90 requires a contiguous array be passed, which might require a contiguous copy to be made, and then copied back on return. Sometimes the decision to make the copy is done at runtime. Gah4 (talk) 01:19, 7 April 2018 (UTC)
thread_title: Fortran incorrect

message: 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 documentationhttps://docs.python.org/3/reference/executionmodel.html#naming-and-binding. 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)
thread_title:  On "Call by sharing" and Java 

message: 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)
replies: text: I support this. It is not strictly a "call by" mechanism, but it certainly is used to "pass" parameters and results.Note it does not need to be global, a known and accessible allocation from previous scopes may suffice. Like a variable placed in a register by an optimizing compiler. Musaran (talk) 22:21, 15 November 2023 (UTC)
thread_title:  global variables 

message: 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)
replies: text: You may be right for pass by reference vs pass by value, but call by value, call by name, call by need, and call by push value are technical terms.  Although you may disagree with its naming, Wikipedia can't and shouldn't try to change the standard terminology. Ebf526 (talk) 20:01, 2 July 2021 (UTC)
thread_title:  Variables are not called 

message: 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?.
: I added a section, and cleaned up the earlier part of the article to distinguish non-strict from lazy. I didn't use the Id manual, that doesn't even use the phrase "lenient evaluation". --Mathnerd314159 (talk) 22:52, 7 January 2022 (UTC)
thread_title:  Lenient evaluation 

message: 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:
 Nowhere man (talk) 05:47, 9 April 2024 (UTC)
replies: text: No, he later defines "subsumes" as a translation between languages. So that's where you get "an intermediate language that embeds call-by-value and call-by-name". And that is a primary source, with MOS:PUFFERY. If you look at secondary sources they pretty much all say it is an intermediate language or a model of evaluation. It is true that the CBN and CBV lambda calculi are in the same category as CBPV (intermediate languages), but the CBN and CBV evaluation strategies are more general - they can be defined for any argument-passing mechanism. My search did not uncover any such generalization of CBPV to argument-passing. There is some speculation in this paper that some sort of hybrid, polarized evaluation strategy similar to CBPV would be possible, but it is just that - speculation, left to future work, not a reliable observation that can be cited by Wikipedia. Mathnerd314159 (talk) 18:50, 9 April 2024 (UTC)
thread_title:  call-by-push-value