«

On Thu, 20 May 2010 at 09:08:53, in comp.lang.javascript, Richard
Cornford wrote:
>On May 20, 4:18 pm, John G Harris wrote:
>> On Wed, 19 May 2010 at 09:22:43, Richard Cornford wrote:
>>
>><snip>>while you can observe the
>>> modification to an object and conclude that there must
>>> be some 'referencing' mechanism that has all values that
>>> are objects 'referring' to the single object
>>
>> <snip>
>>
>> Have you found the words in ECMA 262 that actually say
>> that? If you have please tell me where as I haven't. It
>> seems to be 'common knowledge' but not explicit.
>
>The words that actually say what exactly? There are no words in the
>spec that say "can ... conclude", the ability to do that as a result
>of the observation is evidently a fact (as at least one person has
>done so).

Yes, I didn't say it very clearly. I want to know which words in ECMA
262 say that you can get at the insides of the same object via two
different variables. I've finally managed to plough through the many
sections of the standard needed to find the answer.

Suppose you execute these two statements :

b = new Object();
c = b;

and follow the formal ES3 definitions of what will happen. After tracing
through all the gets, puts, returns, etc. you will find that the 'value'
of b *is* the newly created object, and the 'value' of c is also that
same object. Thus any change to the insides of the new object made via b
is also visible via c.

Obviously, the meaning of 'value' in ECMAScript is somewhat different to
its meaning in other languages.

If 'value' seems confusing then we can turn to the informal ES3 Overview
section where properties are said to be containers. Each property, and
so each variable, is said to contain either a primitive value or an
object. Thus both b and c contain the same newly created object in the
same way that both New York and North America contain Wall Street.
Unlike real geography, an object can indirectly contain itself, making
life difficult for the garbage collector.

If you ask whether function arguments are passed by this or by that or
by something else in ECMAScript the only correct answer is that all
arguments are passed by containment. Any disagreement can only be about
which feature of which other language it most closely resembles.

The ES5 standard adds much complication to the formal definitions but
appears to make no essential difference to these conclusions.

John
--
John Harris

On May 23, 11:52 am, John G Harris wrote:
> On Thu, 20 May 2010 Richard Cornford wrote:
>>On May 20, 4:18 pm, John G Harris wrote:
>>> On Wed, 19 May 2010 at 09:22:43, Richard Cornford wrote:
>>>> while you can observe the
>>>> modification to an object and conclude that there must
>>>> be some 'referencing' mechanism that has all values that
>>>> are objects 'referring' to the single object
>>> <snip>
>>> Have you found the words in ECMA 262 that actually say
>>> that? If you have please tell me where as I haven't. It
>>> seems to be 'common knowledge' but not explicit.
>
>> The words that actually say what exactly? There are no
>> words in the spec that say "can ... conclude", the ability
>> to do that as a result of the observation is evidently a
>> fact (as at least one person has done so).
>
> Yes, I didn't say it very clearly. I want to know which words
> in ECMA 262 say that you can get at the insides of the same
> object via two different variables. I've finally managed to
> plough through the many sections of the standard needed to
> find the answer.

That will save me having to look up all the references in that spec.

> Suppose you execute these two statements :
>
> b = new Object();
> c = b;
>
> and follow the formal ES3 definitions of what will happen. After
> tracing through all the gets, puts, returns, etc. you will find
> that the 'value' of b *is* the newly created object, and the
>'value' of c is also that same object. Thus any change to the
> insides of the new object made via b is also visible via c.
>
> Obviously, the meaning of 'value' in ECMAScript is somewhat
> different to its meaning in other languages.

Probably at least some other languages, maybe most (I don't want to
think about that at the moment). We have a situation where a value can
be an object; the object *is* a value. We can be pretty sure, from
experience of how computers work, that an implementation is going to
be achieving that by employing some sort of reference, but that isn't
a concern of ECMAScript itself. ECMAScript stops at asserting that
objects are values.

> If 'value' seems confusing then we can turn to the informal ES3
> Overview section where properties are said to be containers.
> Each property, and so each variable, is said to contain either
> a primitive value or an object. Thus both b and c contain the
> same newly created object in the same way that both New York
> and North America contain Wall Street.

Wouldn't you b and c example above be better paralleled with, say,
Boston and New York both containing Wall Street?

> Unlike real geography,

I don't think geography is going to prove that useful in this case.

> an object can indirectly contain itself,
> making life difficult for the garbage collector.
>
> If you ask whether function arguments are passed by this or by
> that or by something else in ECMAScript the only correct answer
> is that all arguments are passed by containment.

Are they? If we accept 'properties "contain" values (so may contain
objects as objects are values)' then if the mechanics of passing
arguments to function calls does not involve properties of objects (at
any distinct step) then they will not be contained at that point, and
may not be being "passed by containment". (I may propose that at the
point of the having the result of the call to the internal GetValue
function in the algorithm for evaluating an Arguments list (11.2.4
(3rd Ed.)) represents having only the value, without any 'container'.)

Suppose we attempt to address this question form the other end, and
instead of worrying about how an argument is passed to a function call
instead look at how a function call receives its arguments. In
ECMAScript terms a function call always 'receives its arguments as
(ECMAScript) values'. This is guaranteed by the GetValue call in the
Arguments list algorithm, and it is here that the implications for the
possible 'passing on' of - this - values come from (there can be no
Reference types received as arguments to function calls).

> Any disagreement can only be about which feature of which
> other language it most closely resembles.

While that disagreement is evident I doubt that will prove the "only"
subject of disagreement.

> The ES5 standard adds much complication to the formal definitions
> but appears to make no essential difference to these conclusions.

That is my impression too.

Richard.

On May 20, 6:37 pm, Tim Streater wrote:
> Richard Cornford wrote:
<snip>
>> However, it has been pointed out that there are cases where the
>> complier can observe variables, being assigned number values, and
>> being employed in such a way as to, say, guarantee that a 32 bit
>> signed integer could do the job (i.e. a loop counter starting at
>> zero and counting up to some known value).
>
> You mean e.g. and not i.e.

I may have meant e.g., if I could think of a single other example.

Richard.

In article
<ad80618d-33a2-46af-b47d->,
Richard Cornford <> wrote:

> On May 20, 6:37 pm, Tim Streater wrote:
> > Richard Cornford wrote:
> <snip>
> >> However, it has been pointed out that there are cases where the
> >> complier can observe variables, being assigned number values, and
> >> being employed in such a way as to, say, guarantee that a 32 bit
> >> signed integer could do the job (i.e. a loop counter starting at
> >> zero and counting up to some known value).
> >
> > You mean e.g. and not i.e.
>
> I may have meant e.g., if I could think of a single other example.

That *you* can't/couldn't think of another example makes no difference.

--
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689

Richard Cornford <> writes:

> I may have meant e.g., if I could think of a single other example.

Other examples:

The operands or result of any bitwise operation other than >>>, which
needs a 32-bit unsigned integer for the result (but you can ignore
that if it's used as operand of another bitwise operation).

The return value of String.prototype.charCodeAt. (The problem is
to recognize that that is the function being called).

/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

On May 24, 5:22 pm, Lasse Reichstein Nielsen wrote:
> Richard Cornford writes:
>> I may have meant e.g., if I could think of a single other
>> example.
>
> Other examples:
>
> The operands or result of any bitwise operation other than
> >>>, which needs a 32-bit unsigned integer for the result
> (but you can ignore that if it's used as operand of another
> bitwise operation).

I assume you mean numeric literal operands. So if - x|0 - there is no
need to create an IEEE double from the '0' as a 32 bit (or even
smaller) integer will do? It is not nearly so easy to do that for the
'x'.

> The return value of String.prototype.charCodeAt. (The problem
> is to recognize that that is the function being called).

When you do a math operation with that return value don't you need to
be checking its type in order not to handle it as an IEEE double
precision floating point number? Then, isn't there an implied overhead
of extra type checking for all math operations?

Richard.

Richard Cornford <> writes:

> On May 24, 5:22 pm, Lasse Reichstein Nielsen wrote:

>> The operands or result of any bitwise operation other than
>> >>>, which needs a 32-bit unsigned integer for the result
>> (but you can ignore that if it's used as operand of another
>> bitwise operation).
>
> I assume you mean numeric literal operands. So if - x|0 - there is no
> need to create an IEEE double from the '0' as a 32 bit (or even
> smaller) integer will do? It is not nearly so easy to do that for the
> 'x'.
>
>> The return value of String.prototype.charCodeAt. (The problem
>> is to recognize that that is the function being called).
>
> When you do a math operation with that return value don't you need to
> be checking its type in order not to handle it as an IEEE double
> precision floating point number? Then, isn't there an implied overhead
> of extra type checking for all math operations?

Yes to both. You need to know both how a value is produced and how
it's going to be used, so that you know whether it is a 32-bit
integer, and whether you can keep it as a 32-bit integer until it is
consumed - without needing runtime checks in either end.

This is on top of using a dual representation of numbers: small
integers for the values that can fit, and full doubles for the
rest. For this, you need a tagging mechanism, and a runtime check
before using any value. In practice, most of the actual values in
Javascript programs turns out to be small integers, and the more
efficient representation saves more than the overhead of tagging.

/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

On Mon, 24 May 2010 at 03:58:52, in comp.lang.javascript, Richard
Cornford wrote:
>On May 23, 11:52 am, John G Harris wrote:

<snip>
>> If 'value' seems confusing then we can turn to the informal ES3
>> Overview section where properties are said to be containers.
>> Each property, and so each variable, is said to contain either
>> a primitive value or an object. Thus both b and c contain the
>> same newly created object in the same way that both New York
>> and North America contain Wall Street.
>
>Wouldn't you b and c example above be better paralleled with, say,
>Boston and New York both containing Wall Street?
>
>> Unlike real geography,
>
>I don't think geography is going to prove that useful in this case.

I was trying to point out that it is possible for two different things
to have the same point in common. A Venn diagram is a better example but
I thought New York would be better known. (Is North America as well
known? I wonder.)


<snip>
>> If you ask whether function arguments are passed by this or by
>> that or by something else in ECMAScript the only correct answer
>> is that all arguments are passed by containment.
>
>Are they? If we accept 'properties "contain" values (so may contain
>objects as objects are values)' then if the mechanics of passing
>arguments to function calls does not involve properties of objects (at
>any distinct step) then they will not be contained at that point, and
>may not be being "passed by containment". (I may propose that at the
>point of the having the result of the call to the internal GetValue
>function in the algorithm for evaluating an Arguments list (11.2.4
>(3rd Ed.)) represents having only the value, without any 'container'.)
>
>Suppose we attempt to address this question form the other end, and
>instead of worrying about how an argument is passed to a function call
>instead look at how a function call receives its arguments. In
>ECMAScript terms a function call always 'receives its arguments as
>(ECMAScript) values'. This is guaranteed by the GetValue call in the
>Arguments list algorithm, and it is here that the implications for the
>possible 'passing on' of - this - values come from (there can be no
>Reference types received as arguments to function calls).
<snip>

It's what the function's code sees that matters. According to the formal
description, it sees values that have been passed on by several Returns,
held in a sequence of values, and have finally landed inside the
properties of the arguments object and inside local variables (which are
also properties).

It's what the code sees in those properties that determines what kind of
'pass-by-' is happening.

John
--
John Harris