ECMA-262-3 in detail. Chapter 8. Evaluation strategy.
in [JavaScript]
|
From: Ry Nohryb on 25 Apr 2010 16:21 On Apr 25, 8:25 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: > Hi Jorge (aka Ry Nohryb), > > > 1.- In the section "General Theory" you could as well say that the > > order in which the arguments are evaluated in well specified in ES > > (unlike in other languages, notably, C), it is from left to right. > > This is of great importance if you happen to code something like this: > > foo(a++, a+b); > > Yep, fair enough. But it doesn't relate much to exactly passing from > the outside strategy. More, it e.g. can differ in evaluation if- > conditions. But it depends also on complier version. http://dmitrysoshnikov.com/ecmascript/chapter-8-***evaluation***strategy***/ http://en.wikipedia.org/wiki/Evaluation_strategy <quote> In computer science, an evaluation strategy is a set of (usually deterministic) rules for evaluating expressions in a programming language. Emphasis is typically placed on functions or operators: an evaluation strategy defines when *and*in*what*order*the arguments to a function are evaluated </quote> It couldn't be any more directly related to function calls. The point is that in JavaScript the order of evaluation of the arguments of a function call is specified by the ECMA specs, unlike in other languages such as C whose specs leave it at the discretion of the implementers. > (...) > Then, in both (discussing) > languages we should use prefix-increment operation: > > testFn(++a, a + b); > > That's it. No Dmitry that's not it, with left to right evaluation you get a thing and with right to left evaluation you'd get a different thing. That's it. It has nothing to do with pre/postfix incrementing. > (...) I'll reply to the rest in a separate post. -- Jorge.
From: Ry Nohryb on 26 Apr 2010 06:40 On Apr 25, 8:25 pm, "Dmitry A. Soshnikov" <dmitry.soshni...(a)gmail.com> wrote: > > Hi Jorge (aka Ry Nohryb), > > > 1.- In the section "General Theory" you could as well say that the > > order in which the arguments are evaluated in well specified in ES > > (unlike in other languages, notably, C), it is from left to right. > > This is of great importance if you happen to code something like this: > > foo(a++, a+b); > > Yep, fair enough. But it doesn't relate much to exactly passing from > the outside strategy. More, it e.g. can differ in evaluation if- > conditions. The title of your article is **evaluation**strategy** See what the wikipedia says about it: http://en.wikipedia.org/wiki/Evaluation_strategy <quote> In computer science (...) evaluation strategy defines when *and*in*what*order*the arguments to a function are evaluated </quote> > But it depends also on complier version. E.g. in MS studio > 2005 I have the same result for evaluation this code -- both (C++ and > SpiderMonkey) evaluate it from left to right: My point being that it does *not* depend on the compiler version, for, unlike in C, in JS the order is specified in the ECMA-262 specs. IOW, you can rest on the fact that it's going to be left to right, ever, in every JS engine. > (...) > > Then, in both (discussing) > > languages we should use prefix-increment operation: > > > > testFn(++a, a + b); > > > > That's it. No Dmitry that's not it, with left to right evaluation you get a thing and with right to left evaluation you get a different thing. That's it. It has nothing to do with pre/postfix incrementing. That's why knowing what the order is is important. And that's why knowing that it's always going to be the same, because it's in the ECMA specs, is important too. -- Jorge.
From: Dmitry A. Soshnikov on 26 Apr 2010 10:10 On Apr 26, 2:26 pm, Ry Nohryb <jo...(a)jorgechamorro.com> wrote: > Dmitry A. Soshnikov wrote: <snip> > > > Well, C/C++ has call-by-reference "sugar". And in this case formal > > parameter will be direct alias of the object from the outside. It > > doesn't require dereferencing operation. And assigning to the > > reference -- change object completely, but not assign this name to the > > new address as it would be in case of by-pointer/by-sharing. > > No, C does *not* have a reference datatypevoid f (type ¶m) > { ... } is not valid C syntax. > Excuse me? Why this code isn't valid? If you want to provide some quote from C-specification, -- no, sorry, I'm not interested in current case. But this code is valid and means "call-by-reference". > > Regarding C/C++ (but regardless, that its implementation is just "one > > of") -- yeah, we say that we deal with reference in both case: with > > passing by pointer and with passing by reference. > > There's no reference type in plain C, K&R-C nor ANSI-C. I'd have to > check it for C-99, but I'd say off the top of my head that neither. > It doesn't matter in discussing question. > > > > Moreover, as I > > mentioned above, by-reference -- is just a syntactic sugar which is > > useful in case when we want to affect object of the caller inside the > > function but without using dereferencing operation. > > > void foo(int &bar) { > > bar = 20; // it is not a pointer, but reference -- an alias > > } > > > int x = 10; > > foo(x); // pass by reference > > > cout << x; // 20 > > > But, as it is a sugar, it's the same as: > > > void foo(int *bar) { > > *bar = 20; // it is a pointer, not reference > > } > > (type ¶m) is not the same as (type *param). Thanks you, I know. If you want to nit-picking to words, sorry -- not with me ;) Once again, C/C++ implementation is just "one of". But on this implementation we can see theoretical description of by-reference and by-pointer/sharing. > > > In C it is possible to pass by-reference and by-pointer. > > Again, no. > Jorge, you don't think that I will participate in useless holy wars on several pages of c.l.js topics with nit-picking to irrelevant concepts, yes? Ok. There are a lot of here, and without me ;) > >> I think that this matter is turning into a kind of holy war. If I were > >> to write on this matter, I would avoid any attempt to force a > >> terminology for as you should see there are good reasons for using any > >> of them, and different people coming from different languages are used > >> to call it differently, and none of them is wrong. > > > Yes, as I said, the main purpose of the theoretical article is to > > clarify deeply some aspects (including terminological). It is not > > about everyday speaking where we can say that object is passed by > > reference (meaning that we can change it's properties inside the > > function). > > A theoretical article that attempts to enforce your own preferences on > the reader. > Well, that your choice how to see and treat it. > > I saw similar question many times on forums. Please notice, in case of > > C++ by-reference we would have {x: 20}. But in case of C++ by-pointer > > (which is by-sharing) -- would not (excluding dereferencing, i.e. a > > "safe pointer"). > > I know. That's why in my post C++ wasn't mentioned, not even once. > That's exactly I'm telling you. But I don't see any sense to talk about "no, it is not for C", when you meant C++. I think such arguments are irrelevant and just robs our time, don't you think so? I'm not interested in C/ANSI C/C++ or whatever in this case. We talked about "by-reference" and "by-sharing/pointer" and just use C/C++ (all of them! -- regardless your useless nit-picking to "K&R, ANSI") to show an example. That's it. No more, no less. > >> [*1] If you're interested, I can provide you an example that proves > >> this point. What you say in "By sharing and pointers" : > > >> <quote> > >> Regarding C, C++, this strategy is ideologically similar to passing by > >> pointer values, but with one important difference -- that it is > >> possible to dereference the pointer and to change the object > >> completely. > >> </quote> > > >> is wrong. > > > No, it is correct. See example below. > > It is not, not for C. > Again. It doesn't matter for me "not for C" or "not for C++". Really. But, I think we already understand each other, right? ;) Dmitry.
From: Dmitry A. Soshnikov on 26 Apr 2010 10:15 On Apr 26, 2:40 pm, Ry Nohryb <jo...(a)jorgechamorro.com> wrote: <snip> > In computer science (...) evaluation strategy defines when > *and*in*what*order*the arguments to a function are evaluated Yes, OK, maybe I'll add this sentence in the article; will be useful. <snip> > No Dmitry that's not it, with left to right evaluation you get a thing Thanks, I know, and was talking about *only this* type -- left to right in both cases. > and with right to left evaluation you get a different thing. That's > it. Yep, I know, thanks. Dmitry.
From: John G Harris on 26 Apr 2010 10:28
On Sun, 25 Apr 2010 at 11:25:31, in comp.lang.javascript, Dmitry A. Soshnikov wrote: <snip> >I repeat, regardless that reference-concept is just a >sugar for the pointer in C++, <snip> That isn't true. In C++ a reference is a synonym. The compiler doesn't have to use a pointer. If it's possible and if it wants to it can treat it like a macro instead. (See 'frog', use 'jump'). John -- John Harris |