Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #27819 > unrolled thread

Identity of values in Javascript

Back to article view | Back to comp.lang.javascript

Contents

  Identity of values in Javascript Steven D'Aprano <steve@pearwood.info> - 2015-05-22 22:47 +1000
    Re: Identity of values in Javascript Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-22 19:17 +0100
      Re: Identity of values in Javascript Steven D'Aprano <steve@pearwood.info> - 2015-05-23 05:02 +1000
        Re: Identity of values in Javascript Steven D'Aprano <steve@pearwood.info> - 2015-05-23 05:25 +1000
        Re: Identity of values in Javascript "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2015-05-22 23:51 +0200
        Re: Identity of values in Javascript Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-23 00:24 +0100
          Re: Identity of values in Javascript Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-23 09:35 +0200
            Re: Identity of values in Javascript Steven D'Aprano <steve@pearwood.info> - 2015-05-23 23:04 +1000
          Re: Identity of values in Javascript "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-05-23 22:27 +0200
            Re: Identity of values in Javascript Steven D'Aprano <steve@pearwood.info> - 2015-05-25 01:58 +1000
          Re: Identity of values in Javascript Steven D'Aprano <steve@pearwood.info> - 2015-05-25 02:12 +1000
            Re: Identity of values in Javascript Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-24 23:33 +0100
              Re: Identity of values in Javascript Steven D'Aprano <steve@pearwood.info> - 2015-05-25 21:47 +1000
                Re: Identity of values in Javascript Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-26 00:10 +0100
                  Re: Identity of values in Javascript Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-26 17:34 +0200
                    Re: Identity of values in Javascript Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-05-26 17:03 +0100
                      Re: Identity of values in Javascript Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-26 18:31 +0200
                        Re: Identity of values in Javascript Steven D'Aprano <steve@pearwood.info> - 2015-05-27 23:40 +1000
                          Re: Identity of values in Javascript Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2015-05-27 23:21 -0300
                            Re: Identity of values in Javascript "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2015-05-27 19:32 -0700
                            Re: Identity of values in Javascript Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-28 22:38 +0200
                    Re: Identity of values in Javascript Scott Sauyet <scott.sauyet@gmail.com> - 2015-05-26 09:06 -0700
                    Re: Identity of values in Javascript Steven D'Aprano <steve@pearwood.info> - 2015-05-27 23:02 +1000
      Re: Identity of values in Javascript Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-23 00:02 +0200
      Re: Identity of values in Javascript Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-05-23 09:19 +0200
    Re: Identity of values in Javascript Steven D'Aprano <steve@pearwood.info> - 2015-05-23 05:20 +1000

Page 1 of 2  [1] 2  Next page →

#27819 — Identity of values in Javascript

Hi, I'm a newbie when it comes to Javascript, and I'm trying to understand
some aspects of the language model. Please correct me if I'm wrong.

Javascript has two kinds of values, simple values or primitives, and
objects. There are three primitive types: number, string and boolean.
Primitives are implemented as simple machine types. Everything else is an
object.

var a = 23;  // a primitive
var b = {};  // an object
var c = [1, 2]  // arrays are objects too


I understand that for primitives, if I pass a value to a function,
Javascript uses pass by value: the value is copied. (This is the same
behaviour as, say, C or Pascal.) While accepting that on faith is fine, I'd
like to actually demonstrate it with some Javascript code.

In C or Pascal, I could use the "address of" operator to compare the value
inside the function with the value outside the function, to see if they
referred to the same memory location. In Javascript, I could use something
like this:


function test(arg) {
    if (addr(arg) != addr(x)) {
        return "copied"
    }
    else {
        return "not copied"
    }
}

x = 23;
print(test(x));  // I'm using the rhino shell.


except that there's no "addr" function that returns the address of a value.

In Ruby I would use "arg.equal? x", in Python I would use "arg is x", and in
Lua I would use "rawequal(arg, x)". Is there anything I can write in
Javascript to demonstrate that when I pass a primitive value into a
function, it is copied, but when I pass an object into the function, it is
not?


Thanks in advance,



-- 
Steven

[toc] | [next] | [standalone]

#27826

Steven D'Aprano <steve@pearwood.info> writes:

> Hi, I'm a newbie when it comes to Javascript, and I'm trying to understand
> some aspects of the language model. Please correct me if I'm wrong.
>
> Javascript has two kinds of values, simple values or primitives, and
> objects. There are three primitive types: number, string and boolean.
> Primitives are implemented as simple machine types. Everything else is an
> object.

The ECMAScript types are named with capitals, and there are a couple
more (Null and Undefined) but that's neither here nor there as far as
your point goes.  Also I'm not sure I'd say that String is implemented
as a simple machine type -- it's a relatively complex type compared to,
say, Number, -- but, again, that's not your point.

> var a = 23;  // a primitive
> var b = {};  // an object
> var c = [1, 2]  // arrays are objects too
>
> I understand that for primitives, if I pass a value to a function,
> Javascript uses pass by value: the value is copied. (This is the same
> behaviour as, say, C or Pascal.) While accepting that on faith is fine, I'd
> like to actually demonstrate it with some Javascript code.
>
> In C or Pascal, I could use the "address of" operator to compare the value
> inside the function with the value outside the function, to see if they
> referred to the same memory location.

In C and in Pascal values don't have addresses so you can't tell if a
value is copied by taking the address of anything.

In C, you can be certain that the object (using the C term) named by the
parameter has a unique address distinct from that of all of the objects
during its lifetime, but that's it.  You know you get a copied value
because of the way the semantics of function calling is defined.

Informally, I'd describe ECMAScript argument passing as call by sharing
(as in Python) because that's how it behaves.  The full specification is
in ECMA 262 edition 5.1 (there's a new version, 6, on the way).  People
more expert than I will step in to say where (if anywhere) the corner
cases are that make this informal description untrue.

> In Javascript, I could use something
> like this:
>
>
> function test(arg) {
>     if (addr(arg) != addr(x)) {
>         return "copied"
>     }
>     else {
>         return "not copied"
>     }
> }
>
> x = 23;

This is a little odd in ECMAScript.  Put a 'var' in front to make a new
named variable.  Otherwise you are adding (or modifying) the 'x'
property to the global object.

> print(test(x));  // I'm using the rhino shell.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#27829

On Sat, 23 May 2015 04:17 am, Ben Bacarisse wrote:

> Steven D'Aprano <steve@pearwood.info> writes:
> 
>> Hi, I'm a newbie when it comes to Javascript, and I'm trying to
>> understand some aspects of the language model. Please correct me if I'm
>> wrong.
>>
>> Javascript has two kinds of values, simple values or primitives, and
>> objects. There are three primitive types: number, string and boolean.
>> Primitives are implemented as simple machine types. Everything else is an
>> object.
> 
> The ECMAScript types are named with capitals, and there are a couple
> more (Null and Undefined) but that's neither here nor there as far as
> your point goes.  Also I'm not sure I'd say that String is implemented
> as a simple machine type -- it's a relatively complex type compared to,
> say, Number, -- but, again, that's not your point.

True :-) but thanks for the correction anyway.

As I said, I'm new to Javascript, and I keep finding sources that refer to
(say) lower case string, and distinguish it from String. E.g.:

https://developer.mozilla.org/en-US/docs/Glossary/Primitive


[quote]
In JavaScript, there are 6 primitive data types:

    string
[...]
    String for the string primitive.
[end quote]


>> var a = 23;  // a primitive
>> var b = {};  // an object
>> var c = [1, 2]  // arrays are objects too
>>
>> I understand that for primitives, if I pass a value to a function,
>> Javascript uses pass by value: the value is copied. (This is the same
>> behaviour as, say, C or Pascal.) While accepting that on faith is fine,
>> I'd like to actually demonstrate it with some Javascript code.
>>
>> In C or Pascal, I could use the "address of" operator to compare the
>> value inside the function with the value outside the function, to see if
>> they referred to the same memory location.
> 
> In C and in Pascal values don't have addresses so you can't tell if a
> value is copied by taking the address of anything.

I beg to differ. Pascal has the @ operator, which returns the address of the
variable currently holding the value you care about. Admittedly it's not
standard Pascal, but it is available in a number of popular compilers. C
has the & operator. If you want to argue that they return the address of
the variable, not the value, I won't disagree, but state that for my
purposes that is fine.


> In C, you can be certain that the object (using the C term) named by the
> parameter has a unique address distinct from that of all of the objects
> during its lifetime, but that's it.  You know you get a copied value
> because of the way the semantics of function calling is defined.

Yes, and you can confirm it by comparing the address of the function formal
parameter and the address of the variable being used as argument. E.g.
given a function foo with formal parameter a, and a variable b in an
enclosing scope, if I call foo(b), pass by value semantics require that the
addresses &a and &b will be different.


> Informally, I'd describe ECMAScript argument passing as call by sharing
> (as in Python) because that's how it behaves.

That's what I expected, but I've found so many places claiming that
Javascript uses call by value for "simple types" and call by reference
for "reference types" that I wanted to see for myself.

(By the way, I've seen similar confusion and abuse of terminology in the
Ruby, Python and Java camps too.)


> The full specification is 
> in ECMA 262 edition 5.1 (there's a new version, 6, on the way).  People
> more expert than I will step in to say where (if anywhere) the corner
> cases are that make this informal description untrue.
> 
>> In Javascript, I could use something
>> like this:
>>
>>
>> function test(arg) {
>>     if (addr(arg) != addr(x)) {
>>         return "copied"
>>     }
>>     else {
>>         return "not copied"
>>     }
>> }
>>
>> x = 23;
> 
> This is a little odd in ECMAScript.  Put a 'var' in front to make a new
> named variable.  Otherwise you are adding (or modifying) the 'x'
> property to the global object.

Ah, thanks again for the correction.

I only need to use the var declaration once, correct? If I say:

var x = 23;

then later

x = 42;

the second assignment applies to the same x variable as the first. Correct?




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#27832

On Sat, 23 May 2015 05:08 am, Stefan Ram wrote:

> Steven D'Aprano <steve@pearwood.info> writes:
> 
>>On Sat, 23 May 2015 04:17 am, Ben Bacarisse wrote:
> 
>>>In C and in Pascal values don't have addresses so you can't tell if a
>                      ¯¯¯¯¯¯
>>>value is copied by taking the address of anything.
> 
>>I beg to differ. Pascal has the @ operator, which returns the address of
>>the
> 
>>variable currently holding the value you care about.
>  ¯¯¯¯¯¯¯¯

You deleted the part where I said:

"If you want to argue that they return the address of
the variable, not the value, I won't disagree, but state that for my
purposes that is fine."



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#27836

Steven D'Aprano <steve@pearwood.info> wrote on 22 mei 2015 in 
comp.lang.javascript:

> Ah, thanks again for the correction.
> 
> I only need to use the var declaration once, correct? If I say:
> var x = 23;
> then later
> x = 42;
> the second assignment applies to the same x variable as the first. 
> Correct?

Well, x is just a "pointer to a hidden location" where the value is stored.
We call it a variable, a pointer would be more correct, imho.

If you overwrite the x in the sense of storing another value "in it", it 
could very well be the pointer now points to another location. Locations 
that have lost their pointer [or all pointers] will be garbage-collected.

Since an object and an array point to a location of a collection of pointers 
the manipulations have more a feeling of "by reference".

var a = 17;
var b;
b = a; // just copies the VALUE of a in b.
b = 3; // won't change the value "in" a.
alert(a); // 17

var c = ['qqq',3];
alert(c[0]); // qqq
var d;
d = c; // copies the LOCATION of the array.
d[0] = 'xxx'; // will change c[0] too. 
alert(c[0]); // xxx

// however if you now do:
c = 'blah'; // the c as pointer to the array is lost, and:
alert(d[0]); // xxx // d is now the only pointer to the original array

Perhaps it does not feel right, but that is just the way it is.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#27840

Steven D'Aprano <steve@pearwood.info> writes:

> On Sat, 23 May 2015 04:17 am, Ben Bacarisse wrote:
>
>> Steven D'Aprano <steve@pearwood.info> writes:
>> 
>>> Hi, I'm a newbie when it comes to Javascript, and I'm trying to
>>> understand some aspects of the language model. Please correct me if I'm
>>> wrong.
>>>
>>> Javascript has two kinds of values, simple values or primitives, and
>>> objects. There are three primitive types: number, string and boolean.
>>> Primitives are implemented as simple machine types. Everything else is an
>>> object.
>> 
>> The ECMAScript types are named with capitals, and there are a couple
>> more (Null and Undefined) but that's neither here nor there as far as
>> your point goes.  Also I'm not sure I'd say that String is implemented
>> as a simple machine type -- it's a relatively complex type compared to,
>> say, Number, -- but, again, that's not your point.
>
> True :-) but thanks for the correction anyway.
>
> As I said, I'm new to Javascript, and I keep finding sources that refer to
> (say) lower case string, and distinguish it from String. E.g.:

There's no real harm in that and Javascript is a rather vague term
anyway.  Most implementations aim to conform with the ECMAScript
specification and that uses Number etc when talking about the types.

<snip>
>>> var a = 23;  // a primitive
>>> var b = {};  // an object
>>> var c = [1, 2]  // arrays are objects too
>>>
>>> I understand that for primitives, if I pass a value to a function,
>>> Javascript uses pass by value: the value is copied. (This is the same
>>> behaviour as, say, C or Pascal.) While accepting that on faith is fine,
>>> I'd like to actually demonstrate it with some Javascript code.
>>>
>>> In C or Pascal, I could use the "address of" operator to compare the
>>> value inside the function with the value outside the function, to see if
>>> they referred to the same memory location.
>> 
>> In C and in Pascal values don't have addresses so you can't tell if a
>> value is copied by taking the address of anything.
>
> I beg to differ. Pascal has the @ operator, which returns the address
> of the variable currently holding the value you care about. Admittedly
> it's not standard Pascal, but it is available in a number of popular
> compilers. C has the & operator.

No, you beg to agree because I agree with this and it's not at odds with
what I said!

> If you want to argue that they return
> the address of the variable, not the value, I won't disagree, but
> state that for my purposes that is fine.

Now I beg to differ.  I don't think it is enough for your purposes
because it can't tell about situations you are probably interested in
like

  f(42);
  f(g(42));

There is nothing whose address can be compared here.

>> In C, you can be certain that the object (using the C term) named by the
>> parameter has a unique address distinct from that of all of the objects
>> during its lifetime, but that's it.  You know you get a copied value
>> because of the way the semantics of function calling is defined.
>
> Yes, and you can confirm it by comparing the address of the function formal
> parameter and the address of the variable being used as argument. E.g.
> given a function foo with formal parameter a, and a variable b in an
> enclosing scope, if I call foo(b), pass by value semantics require that the
> addresses &a and &b will be different.

You still need to know the semantics of function call.  Having &a != &b
tells you something in C only because of the rest of the things you know
about C (i.e. how a call is defined to work).  I am sure you can imagine
a (nasty) language in which

  var a = 42
  define f(b) if &a != &b print("no address alias"); b = 0
  f(a)
  print(a)

prints "no address alias" and 0.  Ultimately, it's the language
definition that tells you how things get passed, and it's often very
hard to find out by poking about in a particular implementation.

>> Informally, I'd describe ECMAScript argument passing as call by sharing
>> (as in Python) because that's how it behaves.
>
> That's what I expected, but I've found so many places claiming that
> Javascript uses call by value for "simple types" and call by reference
> for "reference types" that I wanted to see for myself.
>
> (By the way, I've seen similar confusion and abuse of terminology in the
> Ruby, Python and Java camps too.)

One person's confusion is another person's explanation.  The term "call
by sharing" is rather opaque.  It does not explain much on its own, so
more usually needs to be said.

>> The full specification is 
>> in ECMA 262 edition 5.1 (there's a new version, 6, on the way).  People
>> more expert than I will step in to say where (if anywhere) the corner
>> cases are that make this informal description untrue.
>> 
>>> In Javascript, I could use something
>>> like this:
>>>
>>>
>>> function test(arg) {
>>>     if (addr(arg) != addr(x)) {
>>>         return "copied"
>>>     }
>>>     else {
>>>         return "not copied"
>>>     }
>>> }
>>>
>>> x = 23;
>> 
>> This is a little odd in ECMAScript.  Put a 'var' in front to make a new
>> named variable.  Otherwise you are adding (or modifying) the 'x'
>> property to the global object.
>
> Ah, thanks again for the correction.
>
> I only need to use the var declaration once, correct?

Yes, it's a declaration.

> If I say:
>
> var x = 23;
>
> then later
>
> x = 42;
>
> the second assignment applies to the same x variable as the
> first. Correct?

Yes, provided x is still in scope.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#27843

Stefan Ram wrote:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> There's no real harm in that and Javascript is a rather vague term
>> anyway.  Most implementations aim to conform with the ECMAScript
>> specification and that uses Number etc when talking about the types.
> 
>   Some say that »JavaScript« is the name of the ECMAScript
>   implementation of Netscape/Mozilla, so:

This is not only that “some” say, but something that is true.  See the ES 
Matrix and referenced material, in particular my thesis linked there and 
material referenced in there, for details.

> console.log( window.navigator.appCodeName );
> "Mozilla"

That does not prove anything.  The value of the “appCodeName” property of 
the “navigator” object is the part of the “navigator.userAgent” value that 
precedes the *application* version.

You get exactly the same value in Chrome/Chromium even though the ECMAScript 
implementation in Chrome/Chromium is Google V8 JavaScript.  Likewise for 
other HTML user agent environments.

The reason for that is that when Microsoft Internet Explorer was published, 
Netscape Navigator with its Mozilla codebase was already around, and people 
would check for that.  To increase their browser’s market share, Microsoft 
used much the same User-Agent string; other vendors did too, so it gradually 
became useless (although nowadays pertinent pieces have been re-added).  
Which is also why browser sniffing *instead of* feature detection is a bad 
idea (but there are edge cases where there is no other way, even for 
experts).

See the ES Matrix (see my sig) for an exclusion algorithm that is capable of 
inferring the used ECMAScript implementation and version in several cases.
 
> console.log( typeof( 2 ));
> "number"

“typeof” is an operator; you should not write it as if it were a function 
call:

  console.log(typeof 2);

>   However, the MDN sometimes uses upper-case and sometimes
>   lower-case spellings for those types.

Example?

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#27846

On Sat, 23 May 2015 05:35 pm, Thomas 'PointedEars' Lahn wrote:

> Stefan Ram wrote:
[...]

> “typeof” is an operator; you should not write it as if it were a function
> call:
> 
>   console.log(typeof 2);

Ah, I didn't know that. Thanks.


>>   However, the MDN sometimes uses upper-case and sometimes
>>   lower-case spellings for those types.
> 
> Example?

https://developer.mozilla.org/en-US/docs/Glossary/Primitive


[quote]
In JavaScript, there are 6 primitive data types:

    string
[...]
    String for the string primitive.
[end quote]



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#27848

Ben Bacarisse wrote:

> Steven D'Aprano <steve@pearwood.info> writes:
> 
>> On Sat, 23 May 2015 04:17 am, Ben Bacarisse wrote:
>> 
>>> Informally, I'd describe ECMAScript argument passing as call by 
>>> sharing (as in Python) because that's how it behaves.
>> 
>> That's what I expected, but I've found so many places claiming that
>> Javascript uses call by value for "simple types" and call by 
>> reference for "reference types" that I wanted to see for myself.
>> (By the way, I've seen similar confusion and abuse of terminology
>> in the Ruby, Python and Java camps too.)

Call-by-reference usually means that you can assign another value to the
variable passed as argument.  That is not possible in ECMAScript
conforming languages (at least to my knowledge).  Consider, for instance:

    var obj = {};
    function change(val) {
        val = 42;
    }
    change(obj);
    console.log(obj);

That is supposed to emit something like `Object {}`, but not `42`.

BTW: even though the ECMAScript specification distinguished primitive
values and objects, this distinction is not absolutely necessary when
using ECMAScript implementations.  Most of the time, one can regard
numbers, booleans, strings etc. simply as being *immutable* objects.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#27853

On Sun, 24 May 2015 06:27 am, Christoph M. Becker wrote:

> Ben Bacarisse wrote:
> 
>> Steven D'Aprano <steve@pearwood.info> writes:
>> 
>>> On Sat, 23 May 2015 04:17 am, Ben Bacarisse wrote:
>>> 
>>>> Informally, I'd describe ECMAScript argument passing as call by
>>>> sharing (as in Python) because that's how it behaves.
>>> 
>>> That's what I expected, but I've found so many places claiming that
>>> Javascript uses call by value for "simple types" and call by
>>> reference for "reference types" that I wanted to see for myself.
>>> (By the way, I've seen similar confusion and abuse of terminology
>>> in the Ruby, Python and Java camps too.)
> 
> Call-by-reference usually means that you can assign another value to the
> variable passed as argument.

Yes, that's the standard meaning -- the function parameter becomes an alias
to the external variable for the duration of the call.


> That is not possible in ECMAScript 
> conforming languages (at least to my knowledge).  Consider, for instance:
> 
>     var obj = {};
>     function change(val) {
>         val = 42;
>     }
>     change(obj);
>     console.log(obj);
> 
> That is supposed to emit something like `Object {}`, but not `42`.
> 
> BTW: even though the ECMAScript specification distinguished primitive
> values and objects, this distinction is not absolutely necessary when
> using ECMAScript implementations.  Most of the time, one can regard
> numbers, booleans, strings etc. simply as being *immutable* objects.

Thanks for the explanation.

You say "most of the time" -- apart from questions of efficiency, are there
any behavioural differences between primitive values and de facto immutable
objects?

 

-- 
Steven

[toc] | [prev] | [next] | [standalone]

#27854

On Sat, 23 May 2015 09:24 am, Ben Bacarisse wrote:

> Steven D'Aprano <steve@pearwood.info> writes:
> 
>> On Sat, 23 May 2015 04:17 am, Ben Bacarisse wrote:
>>
>>> Steven D'Aprano <steve@pearwood.info> writes:
[...]
> Now I beg to differ.  I don't think it is enough for your purposes
> because it can't tell about situations you are probably interested in
> like
> 
>   f(42);
>   f(g(42));
> 
> There is nothing whose address can be compared here.

In the first case, there is the value 42; in the second case it is the value
returned by g(42), whatever that is. Those values must exist *somewhere* in
memory. (I acknowledge the hypothetical existence of exotic computing
architectures which don't use addressable memory, but I'm not interested in
them.) Those addresses may be inaccessible to Javascript code (I guess?),
but they do exist.

Anyway, I'm not hung up over the address of values. The address is only a
means to an end: to confirm whether or not the value in question is copied
on being passed as an argument to a function. (And by value I mean the
ordinary, plain English meaning of the word: 42 is the value, not some
pointer or handle or reference to 42.)

I expect that the answer will be that when it comes to numbers and other
non-object values, there is no Javascript code I can write that will
distinguish whether or not it is copied. I could read the source to see
what any specific implementation does, but that's about it. Am I close?



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#27857

Steven D'Aprano <steve@pearwood.info> writes:

> On Sat, 23 May 2015 09:24 am, Ben Bacarisse wrote:
>
>> Steven D'Aprano <steve@pearwood.info> writes:
>> 
>>> On Sat, 23 May 2015 04:17 am, Ben Bacarisse wrote:
>>>
>>>> Steven D'Aprano <steve@pearwood.info> writes:
> [...]
>> Now I beg to differ.  I don't think it is enough for your purposes
>> because it can't tell about situations you are probably interested in
>> like
>> 
>>   f(42);
>>   f(g(42));
>> 
>> There is nothing whose address can be compared here.
>
> In the first case, there is the value 42; in the second case it is the value
> returned by g(42), whatever that is. Those values must exist *somewhere* in
> memory.

No, a compiler can (and many do) perform optimisations that make the 42
vanish altogether.

But that's something of a red herring.  The point is that the language
does not do what you want.  You proposed using C's & to detect copying
but in these cases you can't.

And in the cases where is can tell you something (say where a plain
variable is the argument) you can't detect the semantics because, to
take one example, argument passing may be defined by copy in and copy
out.  The overall semantics are more important than whether a value
needs to be copied somewhere.

<snip>
> Anyway, I'm not hung up over the address of values. The address is only a
> means to an end: to confirm whether or not the value in question is copied
> on being passed as an argument to a function. (And by value I mean the
> ordinary, plain English meaning of the word: 42 is the value, not some
> pointer or handle or reference to 42.)

I'm just saying the the address of a value, being meaningless in most
programming notations, is not a means to that end.  The simplest means
to that end is to see what the language specification says about
argument passing.  You'll find that C passes by value, despite the fact
that there are many cases where no use of C's & operation can verify
that.

> I expect that the answer will be that when it comes to numbers and other
> non-object values, there is no Javascript code I can write that will
> distinguish whether or not it is copied.  I could read the source to see
> what any specific implementation does, but that's about it. Am I
> close?

I think you've been sidetracked by this address-taking idea.  The
language specification is the way to tell what the semantics of argument
passing are.  That's a lot simpler than looking at an implementation.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#27862

On Mon, 25 May 2015 08:33 am, Ben Bacarisse wrote:

> The
> language specification is the way to tell what the semantics of argument
> passing are.  That's a lot simpler than looking at an implementation.

Assuming that there is a language specification, that it states what the
semantics are in unambiguous detail (specs can be buggy too), that you can
understand the specification (often the specs are more complicated and less
understandable than the code that meets those specs), and that the
implementations actually meet the specification.


I appreciate you guys taking the time to discuss interesting areas of
compiler optimizations and so forth, and I'm not being sarcastic, but I
wrote here with some concrete questions about Javascript. If they have been
answered, I missed them, sorry.

Is there any analogue to Python's "is" operator, Ruby's "equal?" method, or
Lua's "rawequal" function, in Javascript? I think the answer is No,
although === (strict equality) comes closest, at least for objects.

When it comes to passing non-objects, is there any way to tell what calling
convention a specific implementation is using other than reading the source
code? Again, I think the answer is No. Am I right?


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#27877

Steven D'Aprano <steve@pearwood.info> writes:

> On Mon, 25 May 2015 08:33 am, Ben Bacarisse wrote:
>
>> The
>> language specification is the way to tell what the semantics of argument
>> passing are.  That's a lot simpler than looking at an implementation.
>
> Assuming that there is a language specification, that it states what the
> semantics are in unambiguous detail (specs can be buggy too), that you can
> understand the specification (often the specs are more complicated and less
> understandable than the code that meets those specs), and that the
> implementations actually meet the specification.

Of course.  These are all potential problems.  But the code for an
implementation might also have some or all of these problems as well.
In general, the language's reference document (or if they are opaque and
mysterious some reliable digest of is like a textbook) is going to be a
better option.

> I appreciate you guys taking the time to discuss interesting areas of
> compiler optimizations and so forth, and I'm not being sarcastic, but I
> wrote here with some concrete questions about Javascript. If they have been
> answered, I missed them, sorry.

That's a shame; you could try again.  If the post has only concrete
questions there may be less chance of replies getting tied up in more
speculative matters.

> Is there any analogue to Python's "is" operator, Ruby's "equal?" method, or
> Lua's "rawequal" function, in Javascript? I think the answer is No,
> although === (strict equality) comes closest, at least for objects.

No, there is nothing that really matches those identity tests.  ===
tests object identity, but because ECMAScript's object model is so
different from those other languages, it's not analogous to them in the
general case.

> When it comes to passing non-objects, is there any way to tell what calling
> convention a specific implementation is using other than reading the source
> code? Again, I think the answer is No. Am I right?

This seems to be a new question.  The semantics of function calls are
best understood from the specification (it's defined in terms of
environments and bindings) but the phrase "calling convention" usually
refers to something more low-level and implementation-specific.  If
that's what you mean, yes, you are right.  To find out how an
implementation implements calls, you pretty much have to read the code
(unless someone has written about the code of course).

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#27892

Ben Bacarisse wrote:

> Steven D'Aprano <steve@pearwood.info> writes:
>> I appreciate you guys taking the time to discuss interesting areas of
>> compiler optimizations and so forth, and I'm not being sarcastic, but I
>> wrote here with some concrete questions about Javascript. If they have
>> been answered, I missed them, sorry.
> 
> That's a shame; you could try again.  If the post has only concrete
> questions there may be less chance of replies getting tied up in more
> speculative matters.

There are not going to be any concrete *correct* answers until he realizes 
that there is no “Javascript”.  With *all* the implications of that fact.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#27894

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Ben Bacarisse wrote:
>
>> Steven D'Aprano <steve@pearwood.info> writes:
>>> I appreciate you guys taking the time to discuss interesting areas of
>>> compiler optimizations and so forth, and I'm not being sarcastic, but I
>>> wrote here with some concrete questions about Javascript. If they have
>>> been answered, I missed them, sorry.
>> 
>> That's a shame; you could try again.  If the post has only concrete
>> questions there may be less chance of replies getting tied up in more
>> speculative matters.
>
> There are not going to be any concrete *correct* answers until he realizes 
> that there is no “Javascript”.  With *all* the implications of that fact.

You have the knowledge to provide informative and helpful replies even
to questions that use the wrong terms.  I get that you might choose not
to, but that's shame too.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#27896

Ben Bacarisse wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Ben Bacarisse wrote:
>>> Steven D'Aprano <steve@pearwood.info> writes:
>>>> I appreciate you guys taking the time to discuss interesting areas of
>>>> compiler optimizations and so forth, and I'm not being sarcastic, but I
>>>> wrote here with some concrete questions about Javascript. If they have
>>>> been answered, I missed them, sorry.
>>> That's a shame; you could try again.  If the post has only concrete
>>> questions there may be less chance of replies getting tied up in more
>>> speculative matters.
>> There are not going to be any concrete *correct* answers until he
>> realizes that there is no “Javascript”.  With *all* the implications
>> of that fact.
> 
> You have the knowledge to provide informative and helpful replies even
> to questions that use the wrong terms.  I get that you might choose not
> to, but that's shame too.

No, it is not.

  “I do not enlighten those who are not eager to learn,
   nor arouse those who are not anxious
   to give an explanation themselves.
   If I have presented one corner of the square
   and they cannot come back to me with the other three,
   I should not go over the points again.”

     —Confucius

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#27906

On Wed, 27 May 2015 02:31 am, Thomas 'PointedEars' Lahn wrote:

>   “I do not enlighten those who are not eager to learn,
>    nor arouse those who are not anxious
>    to give an explanation themselves.
>    If I have presented one corner of the square
>    and they cannot come back to me with the other three,
>    I should not go over the points again.”


You cannot uniquely specify a square given only one corner -- there is no
way you can give the right answer except by luck.

If you don't believe me, consider a square with one corner at coordinates
(3, 7) using a Cartesian coordinate system. What are the coordinates of the
other three corners?



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#27907

On 27/05/15 10:40, Steven D'Aprano wrote:
> On Wed, 27 May 2015 02:31 am, Thomas 'PointedEars' Lahn wrote:
>
>>    “I do not enlighten those who are not eager to learn,
>>     nor arouse those who are not anxious
>>     to give an explanation themselves.
>>     If I have presented one corner of the square
>>     and they cannot come back to me with the other three,
>>     I should not go over the points again.”
>
>
> You cannot uniquely specify a square given only one corner -- there is no
> way you can give the right answer except by luck.
>
> If you don't believe me, consider a square with one corner at coordinates
> (3, 7) using a Cartesian coordinate system. What are the coordinates of the
> other three corners?
>

Apparently, Thomas copied and pasted a citation in the introduction of 
the 'Eloquent JavaScript':
<http://eloquentjavascript.net/00_intro.html>

And he seems to be confused with Confucius...


-- 
Joao Rodrigues

[toc] | [prev] | [next] | [standalone]

#27908

On Wednesday, May 27, 2015 at 9:22:02 PM UTC-5, J.R. wrote:

> Apparently, Thomas copied and pasted a citation in the introduction of 
> the 'Eloquent JavaScript':
> <http://eloquentjavascript.net/00_intro.html>
> 
> And he seems to be confused with Confucius...

More likely from myself from some time ago. Irrelevant in any case:

<https://groups.google.com/forum/#!original/comp.lang.javascript/tYWdddH7C6k/qzGevHpC__AJ>

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web