Comparing arraies

[Archos]

How to know if 2 arraies are equal? I was expecting that it could be
checked so:

>>> var array1 = [1,2,3,4], array2 = [1,2,3,4];
>>> if (array1 === array2) { console.log("array1 and array2 are equal"); }

Since the comparing of strings or integers works:

var a = "2", b = "2";
if (a === b) { console.log("a == b"); }

[Martin Honnen]

No, for objects (and arrays are objects) the identity is checked, no
comparison of properties or elements is done.
So with e.g.

var a1, a2;

a1 = a2 = [1, 2, 3, 4];

a1 == a2

you get true as the two variables hold references to the same array object.


If you want to compare the elements you will need to define and
implement your own comparison function I think
--

Martin Honnen --- MVP Data Platform Development
http://msmvps.com/blogs/martin_honnen/

[Thomas 'PointedEars' Lahn]

Martin Honnen wrote:

> Archos wrote:
>> How to know if 2 arraies are equal? I was expecting that it could be
>> checked so:
>>>>> var array1 = [1,2,3,4], array2 = [1,2,3,4];
>>>>> if (array1 === array2) { console.log("array1 and array2 are equal"); }
>>
>> Since the comparing of strings or integers works:
>>
>> var a = "2", b = "2";
>> if (a === b) { console.log("a == b"); }
>
> No, for objects (and arrays are objects) the identity is checked, no
> comparison of properties or elements is done.
> So with e.g.
>
> var a1, a2;
>
> a1 = a2 = [1, 2, 3, 4];
>
> a1 == a2
>
> you get true as the two variables hold references to the same array
> object.

Correct. That example might be confusing, though.

> If you want to compare the elements you will need to define and
> implement your own comparison function I think

Not necessarily. One way without a custom comparison function that works
for *simple* cases like this is to compare the string representations of the
Array instances, which are (without overwriting the toString() method) the
comma-separated string representations of the corresponding array's
elements:

/* "1,2,3,4" == "1,2,3,4" */
a1.toString() == a2.toString()

or

String(a1) == String(a2)

or

("" + a1) == ("" + a2)

That is, those two arrays are considered equal if the string representations
of their elements are the same and occur in the same order (if we assume
that both instances use the same toString() method).

The caveat is that the string representations of elements can be the same,
although the elements are different. Consider this:

var o = {foo: 'bar'};
var o2 = {bar: 'baz'};

/* "[object Object]" == "[object Object]" */
[o].toString() == [o2].toString()

Instead of the `==' operator, the `===' operator may be used as well, but it
is neither supposed to add efficiency nor would it add expressive power
(both arguments are of the same type), while it certainly reduces the
backwards-compatibility of the entire code.


PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

> Instead of the `==' operator, the `===' operator may be used as well, but
> it is neither supposed to add efficiency nor would it add expressive power
> (both arguments are of the same type), while it certainly reduces the
> backwards-compatibility of the entire code.

_Operands_, not arguments. We are not talking about a function, but about
an operator.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[Denis McMahon]

On Thu, 26 Jan 2012 18:29:06 +0100, Martin Honnen wrote:

> Archos wrote:
>> How to know if 2 arraies are equal? I was expecting that it could be
>> checked so:
>>
>>>>> var array1 = [1,2,3,4], array2 = [1,2,3,4]; if (array1 === array2) {
>>>>> console.log("array1 and array2 are equal"); }
>>
>> Since the comparing of strings or integers works:
>>
>> var a = "2", b = "2";
>> if (a === b) { console.log("a == b"); }
>
> No, for objects (and arrays are objects) the identity is checked, no
> comparison of properties or elements is done. So with e.g.
>
> var a1, a2;
>
> a1 = a2 = [1, 2, 3, 4];
>
> a1 == a2
>
> you get true as the two variables hold references to the same array
> object.
>
> If you want to compare the elements you will need to define and
> implement your own comparison function I think

It might be easier to compare two vars universally, assuming the JSON
object is available, by:

function are_identical(var1, var2) {
return JSON.stringify(var1) === JSON.stringify(var2);
}

I think this would work for anything that can be stringified by the
JSON.stringify() method.

Rgds

Denis McMahon

[Michael Haufe (TNO)]

Two arrays are equal iff they have equal elements in respective
positions:

var a1 = [1,2,3,4], a2 = [1,2,3,4];

a1.every(function(e,i){ return e === a2[i]}); //true

a1 = a2 = [1, 2, 3, 4];

a1.every(function(e,i){ return e === a2[i]}); //true

var o = {foo: 'bar'}, o2 = {bar: 'baz'};

a1 = [o,o2], a2 = [o2,o];

a1.every(function(e,i){ return e === a2[i]}); //false

a1 = [o,o2], a2 = [o,o2];

a1.every(function(e,i){ return e === a2[i]}); //true

[Denis McMahon]

On Thu, 26 Jan 2012 16:24:04 -0800, Gene Wirchenko wrote:

> On 26 Jan 2012 23:08:55 GMT, Denis McMahon <denismf...@gmail.com>
> wrote:
>
> [snip]

>
>>It might be easier to compare two vars universally, assuming the JSON
>>object is available, by:
>>
>>function are_identical(var1, var2) {
>>return JSON.stringify(var1) === JSON.stringify(var2); }
>>
>>I think this would work for anything that can be stringified by the
>>JSON.stringify() method.
>

> Why not just toString()?
> if (var1.toString()===var2.toString())

var x;
x.fred = 9;
x.jim = 23.654;
x.sue[0] = [15,"mouse",[12,14,5,"BASHER"],543.876];
x.sue[1] = "is x.toString() defined?";

Rgds

Denis McMahon

[Gene Wirchenko]

On 26 Jan 2012 23:08:55 GMT, Denis McMahon <denismf...@gmail.com>
wrote:

[snip]

>It might be easier to compare two vars universally, assuming the JSON
>object is available, by:
>
>function are_identical(var1, var2) {
>return JSON.stringify(var1) === JSON.stringify(var2);
>}
>
>I think this would work for anything that can be stringified by the
>JSON.stringify() method.

Why not just toString()?
if (var1.toString()===var2.toString())

Sincerely,

Gene Wirchenko

[Evertjan.]

Gene Wirchenko wrote on 27 jan 2012 in comp.lang.javascript:

> Why not just toString()?
> if (var1.toString()===var2.toString())

This is why not:

var a = [1,2,3,'qwerty'];
var b = ['1,2',3,'qwerty'];

alert(String(a) === String(b)); // wrongly true

alert(a.toString() === b.toString()); // wrongly true

alert(a.join('+%%%+=') === b.join('+%%%+=')); // false
// only if you are certain that '+%%%+=' is not part of the content.
// even then only valid if the array content is only numeric or string

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

[Thomas 'PointedEars' Lahn]

Denis McMahon wrote:

> Gene Wirchenko wrote:
>> Denis McMahon wrote:
>>> […]

>>> function are_identical(var1, var2) {
>>> return JSON.stringify(var1) === JSON.stringify(var2); }
>>>
>>> I think this would work for anything that can be stringified by the
>>> JSON.stringify() method.
>>
>> Why not just toString()?
>> if (var1.toString()===var2.toString())
>
> var x;
> x.fred = 9;
> x.jim = 23.654;
> x.sue[0] = [15,"mouse",[12,14,5,"BASHER"],543.876];
> x.sue[1] = "is x.toString() defined?";

This code cannot run (as-is; if `x' was assigned a reference to an object
with a `sue' property before, then it *could* work), and does not constitute
a proof at all.

A useful example showing why toString() does not suffice for all cases is

/* "1,2,3,4" == "1,2,3,4" */

[1, [2, 3], 4].toString() == [[1, 2], [3, 4]].toString()

If the JSON property is unavailable or wrong implemented, it can be
emulated, either by using the implementation from <http://json.org/> or
another object serializer.

[Martin Honnen]

Michael Haufe (TNO) wrote:
> On Jan 26, 9:23 am, Archos<raul....@sent.com> wrote:
>> How to know if 2 arraies are equal? I was expecting that it could be
>> checked so:
>>
>>>>> var array1 = [1,2,3,4], array2 = [1,2,3,4];
>>>>> if (array1 === array2) { console.log("array1 and array2 are equal"); }
>>

> Two arrays are equal iff they have equal elements in respective
> positions:
>
> var a1 = [1,2,3,4], a2 = [1,2,3,4];
>
> a1.every(function(e,i){ return e === a2[i]}); //true

I think an additional check that the length of both arrays is the same
is necessary as otherwise solely doing

a1.every(function(e,i){ return e === a2[i]});

with a1 being shorter than a2 might give true for e.g.
a1 = [1, 2, 3];
a2 = [1, 2, 3, 4, 5];
which is likely not intended.

[John G Harris]

On Thu, 26 Jan 2012 at 19:54:19, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:
>Thomas 'PointedEars' Lahn wrote:
>
>> Instead of the `==' operator, the `===' operator may be used as well, but
>> it is neither supposed to add efficiency nor would it add expressive power
>> (both arguments are of the same type), while it certainly reduces the
>> backwards-compatibility of the entire code.
>
>_Operands_, not arguments. We are not talking about a function, but about
>an operator.

Operators are also functions. How else would + be defined?

John
--
John Harris

[Thomas 'PointedEars' Lahn]

John G Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Instead of the `==' operator, the `===' operator may be used as well,
>>> but it is neither supposed to add efficiency nor would it add expressive
>>> power (both arguments are of the same type), while it certainly reduces
>>> the backwards-compatibility of the entire code.
>>
>>_Operands_, not arguments. We are not talking about a function, but about
>>an operator.
>
> Operators are also functions. How else would + be defined?

You are confusing functions with algorithms. The subject of discussion here
is the syntax of the programming language, not the implementation of the
syntax.


PointedEars
--
Sometimes, what you learn is wrong. If those wrong ideas are close to the
root of the knowledge tree you build on a particular subject, pruning the
bad branches can sometimes cause the whole tree to collapse.
-- Mike Duffy in cljs, <news:Xns9FB6521286...@94.75.214.39>

[Dr J R Stockton]

In comp.lang.javascript message <4f21dd07$0$28275$862e...@ngroups.net>,
Thu, 26 Jan 2012 23:08:55, Denis McMahon <denismf...@gmail.com>
posted:

Observe :
A = new Array(5)
B = new Array(6)
for which A[<anything>] = B[<anything>] = undefined; yet String(B) is
visibly longer than String(A).

Note : JSON.stringify(A) -> [null,null,null,null,null]
so JSON cannot tell a null from an undefined (in FF 9.0.1).

Consider
A = [1, [1, 1], 1]
B = [[1, 1], [1, 1]]
String() gives the same for each, but JSON can tell the difference.

But, in general, enough will be reliably known about the array contents
for String() to be safe.

--
(c) John Stockton, nr London, UK. ?@merlyn.demon.co.uk Turnpike 6.05 WinXP.
Web <http://www.merlyn.demon.co.uk/> - FAQ-type topics, acronyms, and links.
Command-prompt MiniTrue is useful for viewing/searching/altering files. Free,
DOS/Win/UNIX now 2.0.6; see <URL:http://www.merlyn.demon.co.uk/pc-links.htm>.

[John G Harris]

On Fri, 27 Jan 2012 at 18:41:05, in comp.lang.javascript, Thomas
'PointedEars' Lahn wrote:
>John G Harris wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Instead of the `==' operator, the `===' operator may be used as well,
>>>> but it is neither supposed to add efficiency nor would it add expressive
>>>> power (both arguments are of the same type), while it certainly reduces
>>>> the backwards-compatibility of the entire code.
>>>
>>>_Operands_, not arguments. We are not talking about a function, but about
>>>an operator.
>>
>> Operators are also functions. How else would + be defined?
>
>You are confusing functions with algorithms. The subject of discussion here
>is the syntax of the programming language, not the implementation of the
>syntax.

1. The syntax specification calls new a keyword and + a punctuator Their
operands/arguments are called expressions. So we aren't discussing the
syntax.

2. In a language where you write add(2,3) what would you call 2 and 3 :
operands or arguments?

All that's special about operators is that they are often invoked using
a non-general format, and they tend to be built into the language.

John
--
John Harris

[Evertjan.]

Dr J R Stockton wrote on 27 jan 2012 in comp.lang.javascript:

> Observe :
> A = new Array(5)
> B = new Array(6)
> for which A[<anything>] = B[<anything>] = undefined; yet String(B) is
> visibly longer than String(A).
>

Only longer,
if you uphold the for javascript clearly wrong dogma,
that an array must be integer continuous from it's bottom to it's top
index.

I would say both arrays are just as short,
having no visible or invisible content.

arr.length just is a sort of missnomer for the read/write value of the
theoretical top index, also wrongly assuming the defined bottom index is
always 0.

[Thomas 'PointedEars' Lahn]

John G Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> John G Harris wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Instead of the `==' operator, the `===' operator may be used as well,
>>>>> but it is neither supposed to add efficiency nor would it add
>>>>> expressive power (both arguments are of the same type), while it
>>>>> certainly reduces the backwards-compatibility of the entire code.
>>>> _Operands_, not arguments. We are not talking about a function, but
>>>> about an operator.
>>> Operators are also functions. How else would + be defined?
>> You are confusing functions with algorithms. The subject of discussion
>> here is the syntax of the programming language, not the implementation of
>> the syntax.
>
> 1. The syntax specification calls new a keyword and + a punctuator

No, the _lexical grammar_ of ECMAScript (Ed. 5.1) says that `new' is a
keyword (section 7.6.1.1), and that `+' is a punctuator (section 7.7).

The _syntactic grammar_ calls `new' and `+' operators, as in "11.2.2 The
`new' Operator" and "11.6.1 The Addition operator (+)".

"Productions of the lexical and RegExp grammars are distinguished by having
two colons “::” as separating punctuation. […]" (section 5.1.2, last
paragraph).

> Their operands/arguments are called expressions.

Correct for "operands", in the syntactic grammar. Operators do not have
arguments; functions (and by extension to OOP, methods) have them.

> So we aren't discussing the syntax.

Yes, we are. `+' is an operator in the syntax of ECMAScript; it has
operands.

> 2. In a language where you write add(2,3) what would you call 2 and 3 :
> operands or arguments?

I get it now: you are trolling again.

> All that's special about operators is that they are often invoked using
> a non-general format, and they tend to be built into the language.

Wrong.


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[John G Harris]

On Sat, 28 Jan 2012 at 21:17:21, in comp.lang.javascript, Thomas

'PointedEars' Lahn wrote:
>John G Harris wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> John G Harris wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>> Instead of the `==' operator, the `===' operator may be used as well,
>>>>>> but it is neither supposed to add efficiency nor would it add
>>>>>> expressive power (both arguments are of the same type), while it
>>>>>> certainly reduces the backwards-compatibility of the entire code.
>>>>> _Operands_, not arguments. We are not talking about a function, but
>>>>> about an operator.
>>>> Operators are also functions. How else would + be defined?
>>> You are confusing functions with algorithms. The subject of discussion
>>> here is the syntax of the programming language, not the implementation of
>>> the syntax.
>>
>> 1. The syntax specification calls new a keyword and + a punctuator
>
>No, the _lexical grammar_ of ECMAScript (Ed. 5.1) says that `new' is a
>keyword (section 7.6.1.1), and that `+' is a punctuator (section 7.7).

So the terms 'keyword' and 'punctuator' are now available for use in
higher layers of the language's syntax specification.

E.g When saying that identifiers exclude keywords.

>The _syntactic grammar_ calls `new' and `+' operators, as in "11.2.2 The
>`new' Operator" and "11.6.1 The Addition operator (+)".

I'm sure you're going to find it quite difficult to prove that a section
title is normative. If you look closely you'll find that the text of
such sections doesn't say which symbols comprise the 'operator'.
E.g As in

"11.1.6 The Grouping Operator
The production PrimaryExpression : ( Expression ) is evaluated as follows:"
...

The word 'operator' is used informally in the standard.

>"Productions of the lexical and RegExp grammars are distinguished by having
>two colons “::” as separating punctuation. […]" (section 5.1.2, last
>paragraph).
>
>> Their operands/arguments are called expressions.
>
>Correct for "operands", in the syntactic grammar. Operators do not have
>arguments; functions (and by extension to OOP, methods) have them.

OOP, indeed.

In C++, the user-defined member function (aka method)

Thing operator+ (Thing t, int) { ... }

will cause

Thing a, b;
b = a + 1;

to compile and execute correctly.

FTR, this is not off-topic : it is entirely possible that one day one of
the javascript languages will allow operator overloading, maybe even
ECMAScript itself.

>> So we aren't discussing the syntax.
>
>Yes, we are. `+' is an operator in the syntax of ECMAScript; it has
>operands.

>> 2. In a language where you write add(2,3) what would you call 2 and 3 :
>> operands or arguments?
>
>I get it now: you are trolling again.

See above.

>> All that's special about operators is that they are often invoked using
>> a non-general format, and they tend to be built into the language.
>
>Wrong.

Tell us what feature an operator has that is not listed there.

Or are you claiming all those university text books that define + as a
function are somehow wrong.


If at the beginning you'd said that "operand is the more usual name"
then there would have been no argument.

John
--
John Harris

[Thomas 'PointedEars' Lahn]

John G Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> John G Harris wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> John G Harris wrote:
>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>>> Instead of the `==' operator, the `===' operator may be used as
>>>>>>> well, but it is neither supposed to add efficiency nor would it add
>>>>>>> expressive power (both arguments are of the same type), while it
>>>>>>> certainly reduces the backwards-compatibility of the entire code.
>>>>>> _Operands_, not arguments. We are not talking about a function, but
>>>>>> about an operator.
>>>>> Operators are also functions. How else would + be defined?
>>>> You are confusing functions with algorithms. The subject of discussion
>>>> here is the syntax of the programming language, not the implementation
>>>> of the syntax.
>>>
>>> 1. The syntax specification calls new a keyword and + a punctuator
>>
>> No, the _lexical grammar_ of ECMAScript (Ed. 5.1) says that `new' is a
>> keyword (section 7.6.1.1), and that `+' is a punctuator (section 7.7).
>
> So the terms 'keyword' and 'punctuator' are now available for use in
> higher layers of the language's syntax specification.

Not "now". Those terms are far from new in the history of the ECMAScript
Language Specification. If only you would get yourself informed before you
posted …

> E.g When saying that identifiers exclude keywords.

That is self-evident. A programming language where identifiers could form a
non-empty intersecting set with keywords would not be overly useful. Only
recently (Ed. 5) ECMAScript has started allowing reserved words in the dot
property accessor notation, because in this evaluation context we *know*
that a keyword's meaning is not intended. It complicates parsing, though,
as there is an additional /IdentifierName/ production now.

>>The _syntactic grammar_ calls `new' and `+' operators, as in "11.2.2 The
>>`new' Operator" and "11.6.1 The Addition operator (+)".
>
> I'm sure you're going to find it quite difficult to prove that a section
> title is normative.

I do not have to prove that, for it is common knowledge that the section of
a technical specification is normative unless marked differently.

> If you look closely you'll find that the text of
> such sections doesn't say which symbols comprise the 'operator'.
> E.g As in
>
> "11.1.6 The Grouping Operator
> The production PrimaryExpression : ( Expression ) is evaluated as
> follows:"
> ...
>
> The word 'operator' is used informally in the standard.

No, it is not. In this case, it is apparent that the /Expression/ is the
(single) operand to the Grouping Operator.

>>> Their operands/arguments are called expressions.
>>
>> Correct for "operands", in the syntactic grammar. Operators do not have
>> arguments; functions (and by extension to OOP, methods) have them.
>
> OOP, indeed.
>
> In C++, the user-defined member function (aka method)

I am aware of operator overloading (e. g. in C++), but we are not discussing
those languages or possible implementations of ECMAScript written in those
languages. We are discussing the syntax of ECMAScript (implementations).
And again, in the syntax of ECMAScript, `+' is an operator; it has operands,
not arguments.

[John G Harris]

On Sun, 29 Jan 2012 at 17:13:01, in comp.lang.javascript, Thomas

'PointedEars' Lahn wrote:
>John G Harris wrote:

<snip a lot of Lahn silliness>

>I am aware of operator overloading (e. g. in C++), but we are not discussing
>those languages or possible implementations of ECMAScript written in those
>languages. We are discussing the syntax of ECMAScript (implementations).
>And again, in the syntax of ECMAScript, `+' is an operator; it has operands,
>not arguments.

Attention! Thomas has forbidden the Mozilla team to contemplate adding
operator overloading in *any* future version of JavaScript ... because
it destroys his case.

Wikipedia and an online dictionary agree with me : operators are just
functions it's convenient to distinguish from other functions.

<http://foldoc.org/operator>
<http://en.wikipedia.org/wiki/Operator_(programming)>

John
--
John Harris

[Thomas 'PointedEars' Lahn]

John G Harris wrote:

> Thomas 'PointedEars' Lahn wrote:
>> John G Harris wrote:
>
> <snip a lot of Lahn silliness>

*plonk*

>> I am aware of operator overloading (e. g. in C++), but we are not
>> discussing those languages or possible implementations of ECMAScript
>> written in those
>> languages. We are discussing the syntax of ECMAScript (implementations).
>> And again, in the syntax of ECMAScript, `+' is an operator; it has
>> operands, not arguments.
>
> Attention! Thomas has forbidden the Mozilla team to contemplate adding
> operator overloading in *any* future version of JavaScript ... because
> it destroys his case.

No, I have not.

> Wikipedia and an online dictionary agree with me : operators are just
> functions it's convenient to distinguish from other functions.
>
> <http://foldoc.org/operator>

And now look up "function" there, stupid.

> <http://en.wikipedia.org/wiki/Operator_(programming)>

That is a reference (a doubtful one at that), but not a proof for your
statement. In fact, it happens to confirm what I have said (although
citations are lacking).

Troll away.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>

[Michael Haufe (TNO)]

On Jan 30, 9:27 am, John G Harris <j...@nospam.demon.co.uk> wrote:

> Wikipedia and an online dictionary agree with me : operators are just
> functions it's convenient to distinguish from other functions.

An operator is not necessarily a function in the strict mathematical
sense. It COULD be a function. For example:

y^2 + 3x = 6

Is not a function, but a relation. Since this is JavaScript we are
talking about and not a Logic Language, Functional language, nor a
Proof assistant, it is generally understood that a "function" really
means "procedure" with potential side-effects.

[John G Harris]

On Mon, 30 Jan 2012 at 12:01:28, in comp.lang.javascript, Michael Haufe
(TNO) wrote:
>On Jan 30, 9:27 am, John G Harris <j...@nospam.demon.co.uk> wrote:
>
>> Wikipedia and an online dictionary agree with me : operators are just
>> functions it's convenient to distinguish from other functions.
>
>An operator is not necessarily a function in the strict mathematical
>sense. It COULD be a function. For example:
>
>y^2 + 3x = 6
>
>Is not a function, but a relation.

But every relation can be re-defined as a function from the inputs to
the set {true, false}. This is what C, etc, do with the == 'relation' :
it's a function that returns a boolean value.

>Since this is JavaScript we are
>talking about and not a Logic Language, Functional language, nor a
>Proof assistant, it is generally understood that a "function" really
>means "procedure" with potential side-effects.

Surely most descriptions of procedures say that they are functions with
no return value (void functions in C terminology).


John
--
John Harris

[Michael Haufe (TNO)]

On Jan 31, 5:06 am, John G Harris <j...@nospam.demon.co.uk> wrote:
>
> But every relation can be re-defined as a function from the inputs to
> the set {true, false}. This is what C, etc, do with the == 'relation' :
> it's a function that returns a boolean value.

Not every relation is a predicate, but I think I understand what you
are trying to say.

This is where Mathematicians and Physicists tend to get sloppy. When
it comes to the hand-manipulation of symbols, Math is more an
impressionistic language than a rigorous one. Generally you'll notice
that the common practice is to treat single element sets and the
single element of that set as the same thing, where clearly they are
not and do not share the same operations:

sqrt 9 != sqrt {9}

One cannot take the sqrt of a set. sqrt is not defined in the Algebra
of Sets.

So while we could step back and just say every function is simply:

f : Set -> Set

That lacks an enormous amount of expressiveness.

> Surely most descriptions of procedures say that they are functions with
> no return value (void functions in C terminology).

But they MIGHT return a value. They could also launch the missiles as
a side-effect. They may not return the same value twice when called
twice. They could also throw exceptions, or a number of other things.
Regardless of whether the word "function" is used as its name or as
part of the description, they clearly are not the same "function" that
has been used mathematically or in PLs with better foundations. In
most PLs the word "function" is more impressionistic than something of
substance.

[John G Harris]

On Mon, 30 Jan 2012 at 19:03:23, in comp.lang.javascript, Thomas

'PointedEars' Lahn wrote:
>John G Harris wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> John G Harris wrote:
>>
>> <snip a lot of Lahn silliness>
>
>*plonk*

***Plonkity plonk***

I could have said Troll! or Newbie! or Idiot! as Thomas would do, but I
said silly; it's more polite.

>>> I am aware of operator overloading (e. g. in C++), but we are not
>>> discussing those languages or possible implementations of ECMAScript
>>> written in those
>>> languages. We are discussing the syntax of ECMAScript (implementations).
>>> And again, in the syntax of ECMAScript, `+' is an operator; it has
>>> operands, not arguments.
>>
>> Attention! Thomas has forbidden the Mozilla team to contemplate adding
>> operator overloading in *any* future version of JavaScript ... because
>> it destroys his case.
>
>No, I have not.

"We are discussing the syntax of ECMAScript" says otherwise.

>> Wikipedia and an online dictionary agree with me : operators are just
>> functions it's convenient to distinguish from other functions.
>>
>> <http://foldoc.org/operator>
>
>And now look up "function" there, stupid.

I look up 'function' in Foldoc and find it says what it ought to say.
What point are you trying to make?

>> <http://en.wikipedia.org/wiki/Operator_(programming)>
>
>That is a reference (a doubtful one at that), but not a proof for your
>statement.

'Proof'? Who said 'proof'? You must be hoping to get the job of
propaganda minister. What I said was that here are two sources that
agree with me.

>In fact, it happens to confirm what I have said (although
>citations are lacking).

Again you'll have to explain. What I see are almost the same words I
used.


>Troll away.

Silly Thomas.


John
--
John Harris

[John G Harris]

On Tue, 31 Jan 2012 at 06:08:57, in comp.lang.javascript, Michael Haufe
(TNO) wrote:
>On Jan 31, 5:06 am, John G Harris <j...@nospam.demon.co.uk> wrote:
>>
>> But every relation can be re-defined as a function from the inputs to
>> the set {true, false}. This is what C, etc, do with the == 'relation' :
>> it's a function that returns a boolean value.
>
>Not every relation is a predicate, but I think I understand what you
>are trying to say.

I'll say it in more detail. The main, or only, part of a relation is
represented by a set of tuples, each with the same number of elements.
The elements in a tuple are the arguments or operands, whichever you
prefer to say. If a tuple is in the set then the relation is true for
those elements, if not then it's false. There is obviously a function
from tuples to bool that gives the same answer.

>This is where Mathematicians and Physicists tend to get sloppy. When
>it comes to the hand-manipulation of symbols, Math is more an
>impressionistic language than a rigorous one.

Professional mathematicians are usually rigorous, but they have an
annoying habit of switching to shorthand notation without saying so. I
suspect it's because they do it to students and expect them to work it
out for themselves, and provide the full gruesome working just once,
yawn, yawn.

>Generally you'll notice
>that the common practice is to treat single element sets and the
>single element of that set as the same thing, where clearly they are
>not and do not share the same operations:
>
>sqrt 9 != sqrt {9}
>
>One cannot take the sqrt of a set. sqrt is not defined in the Algebra
>of Sets.

I think this is more often something computer scientists do.

>So while we could step back and just say every function is simply:
>
>f : Set -> Set
>
>That lacks an enormous amount of expressiveness.

You should also use the partial function symbol, something like |-> .
Functions defined for all sets are very dangerous. (They can't be
represented by sets for a start).

>> Surely most descriptions of procedures say that they are functions with
>> no return value (void functions in C terminology).
>
>But they MIGHT return a value. They could also launch the missiles as
>a side-effect. They may not return the same value twice when called
>twice. They could also throw exceptions, or a number of other things.
>Regardless of whether the word "function" is used as its name or as
>part of the description, they clearly are not the same "function" that
>has been used mathematically or in PLs with better foundations. In
>most PLs the word "function" is more impressionistic than something of
>substance.

To put it crudely, a procedure doesn't have a return statement, so it
can't 'return' a value.

If you want to describe side effects then you have to say that the
function is from system state to system state. The input state includes
places to hold the arguments, and places holding anything else that
affects the result. The output state includes a place to hold the
result, if any, and places holding the consequences of side effects,
including the effects of an exception.

Defining just the arguments and result is only a part of the complete
description, but an important part of course.

As for launching missiles when your sqrt function goes wrong, the output
state simply has more empty missile silos.


John
--
John Harris

[Dr J R Stockton]

In comp.lang.javascript message <1353630.W...@PointedEars.de>,
Mon, 30 Jan 2012 19:03:23, Thomas 'PointedEars' Lahn
<Point...@web.de> posted:

>John G Harris wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> John G Harris wrote:
>>
>> <snip a lot of Lahn silliness>
>
>*plonk*

Plonking someone and continuing to reply to their article is unusually
childish, even for you.

--
(c) John Stockton, nr London UK. ???@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Check boilerplate spelling -- error is a public sign of incompetence.
Never fully trust an article from a poster who gives no full real name.

[Michael Haufe (TNO)]

On Jan 31, 10:08 am, John G Harris <j...@nospam.demon.co.uk> wrote:
> On Tue, 31 Jan 2012 at 06:08:57, in comp.lang.javascript, Michael Haufe
>
> (TNO) wrote:
> >On Jan 31, 5:06 am, John G Harris <j...@nospam.demon.co.uk> wrote:
>
> >> But every relation can be re-defined as a function from the inputs to
> >> the set {true, false}. This is what C, etc, do with the == 'relation' :
> >> it's a function that returns a boolean value.
>
> >Not every relation is a predicate, but I think I understand what you
> >are trying to say.
>
> I'll say it in more detail. The main, or only, part of a relation is
> represented by a set of tuples, each with the same number of elements.
> The elements in a tuple are the arguments or operands, whichever you
> prefer to say. If a tuple is in the set then the relation is true for
> those elements, if not then it's false. There is obviously a function
> from tuples to bool that gives the same answer.

A relation can be redefined using multiple functions, and you can
place those functions into a set. You can then define a function from
that set to the set of booleans. This does not make the latter
function the same as the original relation.

> >One cannot take the sqrt of a set. sqrt is not defined in the Algebra
> >of Sets.
>
> I think this is more often something computer scientists do.

Based on what do you come to this conclusion?

> >So while we could step back and just say every function is simply:
>
> >f : Set -> Set
>
> >That lacks an enormous amount of expressiveness.
>
> You should also use the partial function symbol, something like |-> .
> Functions defined for all sets are very dangerous. (They can't be
> represented by sets for a start).

I suggest glancing at Axiomatic Set Theory then.

> To put it crudely, a procedure doesn't have a return statement, so it
> can't 'return' a value.

Since procedures can branch, and can branch back to the caller, it is
possible to "return". There are versions of SQL with "return"
statements in procedures for example.

> If you want to describe side effects then you have to say that the
> function is from system state to system state. The input state includes
> places to hold the arguments, and places holding anything else that
> affects the result. The output state includes a place to hold the
> result, if any, and places holding the consequences of side effects,
> including the effects of an exception.

That is one possible method, but neither the 'function' of JavaScript
or any other language you've mentioned do this. To repeat what has
been said earlier: it does not matter what word is used in the
language, 'function' is not a true function in the mathematical sense,
nor can all of the operators of the language.

> As for launching missiles when your sqrt function goes wrong, the output
> state simply has more empty missile silos.

And since the language doesn't represent this in its syntax or
semantics, such "functions" are still not.

[John G Harris]

On Tue, 31 Jan 2012 at 18:32:35, in comp.lang.javascript, Michael Haufe
(TNO) wrote:
>On Jan 31, 10:08 am, John G Harris <j...@nospam.demon.co.uk> wrote:

<snip>

>A relation can be redefined using multiple functions, and you can
>place those functions into a set. You can then define a function from
>that set to the set of booleans. This does not make the latter
>function the same as the original relation.

I don't know why you think it's so complicated. You have a function
that, given (2, 3) returns true if 2 < 3, false if not, and the same
rule for all other pairs of numbers. That's all.

When you do
var a = 2 < 3;
the language is using the functional version of < (with extra rules for
NaN and other peculiar values).

>> >One cannot take the sqrt of a set. sqrt is not defined in the Algebra
>> >of Sets.
>>
>> I think this is more often something computer scientists do.
>
>Based on what do you come to this conclusion?

It's my impression based on reading books, articles, and papers.

>> >So while we could step back and just say every function is simply:
>>
>> >f : Set -> Set
>>
>> >That lacks an enormous amount of expressiveness.
>>
>> You should also use the partial function symbol, something like |-> .
>> Functions defined for all sets are very dangerous. (They can't be
>> represented by sets for a start).
>
>I suggest glancing at Axiomatic Set Theory then.

Which do you prefer : ZF or VNB? What I said is true in both.

(Hint: Russel's paradox).

>> To put it crudely, a procedure doesn't have a return statement, so it
>> can't 'return' a value.
>
>Since procedures can branch, and can branch back to the caller, it is
>possible to "return". There are versions of SQL with "return"
>statements in procedures for example.

The definition of procedure and function varies from language to
language. In Pascal they are keywords. A procedure must not have a
return value, a function must. In C and relatives it's common to use
procedure for functions that do not return a value (void functions).

An ECMAScript function cannot be flagged as void, but if it doesn't
return a value or always returns undefined then we can call it a
procedure if we wish. But if it causes arguments then we mustn't use the
word.

>> If you want to describe side effects then you have to say that the
>> function is from system state to system state. The input state includes
>> places to hold the arguments, and places holding anything else that
>> affects the result. The output state includes a place to hold the
>> result, if any, and places holding the consequences of side effects,
>> including the effects of an exception.
>
>That is one possible method, but neither the 'function' of JavaScript
>or any other language you've mentioned do this. To repeat what has
>been said earlier: it does not matter what word is used in the
>language, 'function' is not a true function in the mathematical sense,
>nor can all of the operators of the language.

Have a look at ECMA 262 v5.1, section 15.9.5.27 where it defines a Date
object's setTime method. The method has side effects. The method's
definition describes the changes to the system state outside the return
value.

In what way is this not mathematical?

>> As for launching missiles when your sqrt function goes wrong, the output
>> state simply has more empty missile silos.
>
>And since the language doesn't represent this in its syntax or
>semantics, such "functions" are still not.

It does in C++. It's called 'undefined behaviour'. It's what happens if
you break a rule that the compiler can't catch. E.g if you break a
precondition.


John
--
John Harris

[Michael Haufe (TNO)]

On Feb 1, 11:02 am, John G Harris <j...@nospam.demon.co.uk> wrote:

> I don't know why you think it's so complicated. You have a function
> that, given (2, 3) returns true if 2 < 3, false if not, and the same
> rule for all other pairs of numbers. That's all.

Its more complicated than it has to be because this is different from
what you said earlier:

"But every relation can be re-defined as a function from the inputs to
the set {true, false}."

No matter how you slice it, this statement is false.

> >Based on what do you come to this conclusion?
>
> It's my impression based on reading books, articles, and papers.

As someone who works with Computer Scientists on a daily basis, this
has not been my experience at all, but if that is your impression so
be it.

> >> You should also use the partial function symbol, something like |-> .
> >> Functions defined for all sets are very dangerous. (They can't be
> >> represented by sets for a start).
>
> >I suggest glancing at Axiomatic Set Theory then.
>
> Which do you prefer : ZF or VNB? What I said is true in both.
>
> (Hint: Russel's paradox).

The paradox doesn't exist in either. A trivial search will show this
to anyone truly interested (Axiom 3 in the former, and the use of
classes in the latter). If this fact isn't recognized, I see little
reason to continue.

> The definition of procedure and function varies from language to
> language.

Which I've said more than once already.

> In Pascal they are keywords. A procedure must not have a
> return value, a function must. In C and relatives it's common to use
> procedure for functions that do not return a value (void functions).

I hope this is going somewhere...

> An ECMAScript function cannot be flagged as void, but if it doesn't
> return a value or always returns undefined then we can call it a
> procedure if we wish. But if it causes arguments then we mustn't use the
> word.

Yes, we've come full circle to recognizing that it is arbitrary once
again.

> Have a look at ECMA 262 v5.1, section 15.9.5.27 where it defines a Date
> object's setTime method. The method has side effects. The method's
> definition describes the changes to the system state outside the return
> value.
>
> In what way is this not mathematical?

Because it does not have Referential transparency

> It does in C++. It's called 'undefined behaviour'. It's what happens if
> you break a rule that the compiler can't catch. E.g if you break a
> precondition.

Using a broken language's arbitrary definition (or lack thereof) is
not a counterpoint to what a function is formally defined to be.

[Thomas 'PointedEars' Lahn]

I have to disagree here. That the outcome of a programmatic function, given
the same arguments in the same order, is not necessarily the same always,
and there may be side-effects, is what distinguishes it from a programmatic
operator.

With such a programmatic operator, by definition the outcome must be the
same given the same operand(s) in the same order (or the operator becomes
ambiguous and useless). It is therefore an non-injective *mathematical*
function of the operands, from the sets that the operands may belong to, to
the set of the result type. But it is _not_ a function in the *syntax* of
any programming language, not even C++, because you *need to* tell the two
kinds apart to make sense of the syntax, i. e. to parse the program.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[Michael Haufe (TNO)]

On Feb 1, 2:45 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

First off, I need to correct an error:

"...nor can all of the operators of the language."

s/can/are

Second, I'm not certain what you're disagreeing with exactly. Perhaps
I was ambiguous on something.

[Thomas 'PointedEars' Lahn]

Michael Haufe (TNO) wrote:

I am disagreeing with you when you say that (all) operators in a programming
language ("programmatic operator(s)") are not true functions in the
mathematical sense (are not "mathematical function(s)"). I think they are,
because of the reasons I named above.


PointedEars
--
When all you know is jQuery, every problem looks $(olvable).

[Michael Haufe (TNO)]

On Feb 1, 4:44 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:

> I am disagreeing with you when you say that (all) operators in a programming
> language ("programmatic operator(s)") are not true functions in the
> mathematical sense (are not "mathematical function(s)"). I think they are,
> because of the reasons I named above.

Ah, I see. I am specifically referring to JavaScript though and this
is what I am trying to say with that sentence:

let "x" represent a particular operator

let P(x) represent the claim "x is a function"

¬(∀x P(x))

which is equivalent to:

∃x ¬P(x)

I am not trying to say:

(∀x ¬P(x))

I hope that is clearer (and of course I hope Google Groups doesn't
mangle the quantifiers when I hit submit...).

But now the burden of proof is on me to prove that there exists an
operator which is not a function. Luckily for me and my laziness, this
work has already been done:

<https://drj11.wordpress.com/2008/07/11/javascript-using-numbers-as-
table-keys-considered-harmful/>

So I think x + "" would qualify if x is one of the values mentioned
in the link.

(I took a glance at the 5.1 spec and that note is still there.)

[John G Harris]

On Wed, 1 Feb 2012 at 10:07:23, in comp.lang.javascript, Michael Haufe
(TNO) wrote:
>On Feb 1, 11:02 am, John G Harris <j...@nospam.demon.co.uk> wrote:
>
>> I don't know why you think it's so complicated. You have a function
>> that, given (2, 3) returns true if 2 < 3, false if not, and the same
>> rule for all other pairs of numbers. That's all.
>
>Its more complicated than it has to be because this is different from
>what you said earlier:
>
>"But every relation can be re-defined as a function from the inputs to
>the set {true, false}."

If you misread what I've written then you are bound to be confused.

I still can't work out how you turned "inputs" into multiple functions.
Do you think I'm a fanatical exponent of currying and was describing a
cascade of curried functions?

>No matter how you slice it, this statement is false.

Only when misinterpreting it.

>> >Based on what do you come to this conclusion?
>>
>> It's my impression based on reading books, articles, and papers.
>
>As someone who works with Computer Scientists on a daily basis, this
>has not been my experience at all, but if that is your impression so
>be it.
>
>> >> You should also use the partial function symbol, something like |-> .
>> >> Functions defined for all sets are very dangerous. (They can't be
>> >> represented by sets for a start).
>>
>> >I suggest glancing at Axiomatic Set Theory then.
>>
>> Which do you prefer : ZF or VNB? What I said is true in both.
>>
>> (Hint: Russel's paradox).
>
>The paradox doesn't exist in either. A trivial search will show this
>to anyone truly interested (Axiom 3 in the former, and the use of
>classes in the latter). If this fact isn't recognized, I see little
>reason to continue.

There must be hundreds of text books that explain that Russell's paradox
hasn't been a paradox since the 1920's, but that the name persists.

The better books then go on to prove the theorem that replaces the
paradox, then prove that no function that is defined for *all* sets can
be represented, aka modelled, by a set or sets.

As I said. Such functions are dangerous and only for use by the very
cautious.

>> The definition of procedure and function varies from language to
>> language.
>
>Which I've said more than once already.

But not at the point where you started this sub-thread.

>> In Pascal they are keywords. A procedure must not have a
>> return value, a function must. In C and relatives it's common to use
>> procedure for functions that do not return a value (void functions).
>
>I hope this is going somewhere...
>
>> An ECMAScript function cannot be flagged as void, but if it doesn't
>> return a value or always returns undefined then we can call it a
>> procedure if we wish. But if it causes arguments then we mustn't use the
>> word.
>
>Yes, we've come full circle to recognizing that it is arbitrary once
>again.

You didn't make it very clear that you were arguing that the definition
of 'procedure' is arbitrary.

>> Have a look at ECMA 262 v5.1, section 15.9.5.27 where it defines a Date
>> object's setTime method. The method has side effects. The method's
>> definition describes the changes to the system state outside the return
>> value.
>>
>> In what way is this not mathematical?
>
>Because it does not have Referential transparency

Referential transparency, if you're using the same definition as in
Wikipedia, is certainly convenient for automatic theorem provers, but
doesn't stop you proving things about Date objects.

Nor does lack of it stop you writing correct code.

>> It does in C++. It's called 'undefined behaviour'. It's what happens if
>> you break a rule that the compiler can't catch. E.g if you break a
>> precondition.
>
>Using a broken language's arbitrary definition (or lack thereof) is
>not a counterpoint to what a function is formally defined to be.

Ah, I see what it's all about. You are a language snob. You think that a
pure functional language is the only kind that is first class and
suitable for use by gentlemen.

You feel that languages used to control petrol pumps and implement sat
navs are working class and should be sneered at and are only fit for
common people.

Cobblers.

And another thought. How come Turing machines are modelled as a function
from system state to system state? Does that mean they are not
mathematical?


John
--
John Harris

[Michael Haufe (TNO)]

On Feb 2, 9:10 am, John G Harris <j...@nospam.demon.co.uk> wrote:
> On Wed, 1 Feb 2012 at 10:07:23, in comp.lang.javascript, Michael Haufe
>
> (TNO) wrote:

> If you misread what I've written then you are bound to be confused.
>
> I still can't work out how you turned "inputs" into multiple functions.

Something like that. If that was not what you were saying, very well
then.

> Do you think I'm a fanatical exponent of currying and was describing a
> cascade of curried functions?

You say that like its a bad thing

> Referential transparency, if you're using the same definition as in
> Wikipedia, is certainly convenient for automatic theorem provers, but
> doesn't stop you proving things about Date objects.
>
> Nor does lack of it stop you writing correct code.

I'm sure Wikipedia is close enough. It is not only convenient for
theorem provers, and it does make it much easier without question.

> Ah, I see what it's all about. You are a language snob. You think that a
> pure functional language is the only kind that is first class and
> suitable for use by gentlemen.

You're mostly right. I don't believe the "snob" remark is accurate,
nor the "suitable for use by gentlemen." bit. Of course it seems to me
that at this point you seem more content in attacking my character
than anything else. I won't lose sleep over it though.

> You feel that languages used to control petrol pumps and implement sat
> navs are working class and should be sneered at and are only fit for
> common people.
>
> Cobblers.

...and you've used JavaScript for such things have you? I didn't know
you had such a intuition into what I feel or think.

> And another thought. How come Turing machines are modelled as a function
> from system state to system state? Does that mean they are not
> mathematical?

I think the best answer to your question is another question.

Since everything you do is dictated by the laws of physics, are you
not mathematical? If you write down on a piece of paper "7 + 3 = 1",
is that not mathematical?

Hopefully from this you can recognize that there is a difference in
our usages of the word "mathematical"

To quote Meertens[1989] : "Program construction is a mathematical
activity. By 'mathematical activity' is not
meant: the actual practice of professional mathematicians, but:
establishing properties
of formal objects with perfect certainty..."

But you should probably ignore that quote, since he's a snob by your
definition, and much more of one than I currently am.

I've grown quite tired of this exchange, as it seems to have devolved
into little more than name-calling and has already drifted quite far
from the original topic.

[Thomas 'PointedEars' Lahn]

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> I am disagreeing with you when you say that (all) operators in a
>> programming language ("programmatic operator(s)") are not true functions
>> in the mathematical sense (are not "mathematical function(s)"). I think
>> they are, because of the reasons I named above.
>
> Ah, I see. I am specifically referring to JavaScript though and this
> is what I am trying to say with that sentence:
>
> let "x" represent a particular operator
>
> let P(x) represent the claim "x is a function"
>
> ¬(∀x P(x))
>
> which is equivalent to:
>
> ∃x ¬P(x)
>
> I am not trying to say:
>
> (∀x ¬P(x))
>
> I hope that is clearer (and of course I hope Google Groups doesn't
> mangle the quantifiers when I hit submit...).

Your statement is clear now, as Google Groups positive-surprisingly kept the
Unicode characters intact.

> But now the burden of proof is on me to prove that there exists an
> operator which is not a function. Luckily for me and my laziness, this
> work has already been done:
>
> <https://drj11.wordpress.com/2008/07/11/javascript-using-numbers-as-
> table-keys-considered-harmful/>
>
> So I think x + "" would qualify if x is one of the values mentioned
> in the link.
>
> (I took a glance at the 5.1 spec and that note is still there.)

While the argument on number representation in the referred article might be
solid, a disturbing (but unfortunately common) amount of inaccuracies,
misnomers and misconceptions with regard to its environment can be found
there. This includes, but might not be limited to:

| […] in JavaScript all tables (associative arrays) are indexed by strings,
| and nothing else."

There are _no_ (built-in) "associative arrays" or "tables" in JavaScript
(the programming language). There are *objects* (as required by ES 5.1,
section 8.6, and corresponding sections of earlier Editions, of which
JavaScript is stated by the respective vendor [see below] to be an
implementation of). [How ECMAScript objects are to be implemented in a
programming language is _not_ specified.]

Objects are _not_ "indexed by string". Objects *have properties* with
String-type names, where with Array instances some property names with
numeric representation are special (ES 5.1, 15.4). [That particular
misconception might be a direct result of David Flanagan's listing `['…`]'
as "Array/index operator" in his "JavaScript: The Definitive Reference"
(IIRC).]

| […] when you go a[0] = thing, isn’t that indexing the table `a' with the
| number 0? Well, yes and no.

| So with (small) integer keys there are few possible problems.

`a[0]' is _not_ accessing a "table `a' with the number `0'" or by "integer
key". It is accessing a *property* of an *object* by the numeric
representation of its *property name*. Likewise, a["0"] is accessing the
property with the name "0" (for short: "the '0' property") of the object
*referred to* by the `a' property of the next matching object in the scope
chain (and potentially by other properties of other objects).

| Given the importance of arrays in JavaScript, […]

| When converting numbers to strings JavaScript requires that the
| parsimonious printing rule is applied.

| In principle a JavaScript implementation could make a different choice
| each time it performed the conversion.

| It would of course be insanity for an implementation to do that, but it’s
| still a loophole in the specification, and it should be closed.

The terms JavaScript and ECMAScript are used interchangeably there. But
JavaScript (1.1+) is (merely) *an implementation of* ECMAScript, originally
by (Brendan Eich of) the Netscape Communications Corporation, and later the
Mozilla Organization (Mozilla.org).

The article is speaking about "JavaScript implementations". However, there
are, in a manner of speaking, AFAIK only two production-quality JavaScript
implementations: SpiderMonkey (with improvements TraceMonkey and
JägerMonkey), and Rhino [1, 2]. [There is also a test implementation of
what was then called "JavaScript 2.0", itself an implementation of
Netscape's (Waldemar Horwat's) proposal for ECMAScript Edition 4, called
Epimetheus (as in Greek mythology) [2], see also [3].]

All other implementations that this concerns are *ECMAScript*
implementations. This is important because "varying between
implementations" with regard to the ECMAScript Language Specification means,
of course, "varying between *ECMAScript* implementations".

I will look into said argument later, but this needed pointing out right
now.


PointedEars
___________
[1] <https://developer.mozilla.org/en/JavaScript>
[2] <https://developer.mozilla.org/en/JavaScript_Language_Resources>
[3] "Google Tech Talk – Changes to JavaScript, Part 1: EcmaScript 5", with
Mark Miller, Waldemar Horwat, and Mike Samuel.
<http://www.youtube.com/watch?v=Kq4FpMe6cRs>
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300...@news.demon.co.uk> (2004)

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

> Michael Haufe (TNO) wrote:

> | […] in JavaScript all tables (associative arrays) are indexed by
> | [strings, and nothing else."
>
> There are _no_ (built-in) "associative arrays" or "tables" in JavaScript
> (the programming language). There are *objects* (as required by ES 5.1,
> section 8.6, and corresponding sections of earlier Editions, of which
> JavaScript is stated by the respective vendor [see below] to be an
> implementation of). [How ECMAScript objects are to be implemented in a
> programming language is _not_ specified.]
>
> Objects are _not_ "indexed by string". Objects *have properties* with
> String-type names, where with Array instances some property names with
> numeric representation are special (ES 5.1, 15.4). [That particular
> misconception might be a direct result of David Flanagan's listing `['…`]'
> as "Array/index operator" in his "JavaScript: The Definitive Reference"
> (IIRC).]

I meant "JavaScript: The Definitive Guide" as mentioned in the FAQ. The
relevant section of the Sixth(?) Edition of that book has been reviewed
here (by mere chance) by Richard Cornford and criticised accordingly, while
David Flanagan (by rare appearance here) was not convinced in the following
discussion that this listing could be positively harmful. I might be able
to find the Message-ID later if anyone is interested.

--
PointedEars

[John G Harris]

On Wed, 1 Feb 2012 at 18:22:41, in comp.lang.javascript, Michael Haufe
(TNO) wrote:

<snip>

>But now the burden of proof is on me to prove that there exists an
>operator which is not a function. Luckily for me and my laziness, this
>work has already been done:
>
><https://drj11.wordpress.com/2008/07/11/javascript-using-numbers-as-
>table-keys-considered-harmful/>
>
>So I think x + "" would qualify if x is one of the values mentioned
>in the link.

That's not a good example. That's just a case of a function being partly
specified by the manufacturer, who might regard it as a commercial
secret.

The example you are looking for is the function that returns the current
time. It returns different values at different times, so lacks any
Referential transparency.

John
--
John Harris

[Michael Haufe (TNO)]

On Feb 4, 4:34 am, John G Harris <j...@nospam.demon.co.uk> wrote:
> On Wed, 1 Feb 2012 at 18:22:41, in comp.lang.javascript, Michael Haufe
>
> (TNO) wrote:

> >[...]

> >So I think   x + ""  would qualify if x is one of the values mentioned
> >in the link.

> That's not a good example. That's just a case of a function being partly
> specified by the manufacturer, who might regard it as a commercial
> secret.

You can't be serious...

> The example you are looking for is the function that returns the current
> time. It returns different values at different times, so lacks any
> Referential transparency.

The example I was looking for is a JavaScript "operator" that is not
R.T.

[Dr J R Stockton]

In comp.lang.javascript message <yxqybXCQ...@J.A830F0FF37FB96852AD0
8924D9443D28E23ED5CD>, Sat, 4 Feb 2012 10:34:56, John G Harris
<jo...@nospam.demon.co.uk> posted:

>The example you are looking for is the function that returns the current
>time. It returns different values at different times, so lacks any
>Referential transparency.

I know of a constructor which does that; but is it a function? Of
course, it can be put into an undoubted function. If one's code is
quick enough, it can return the same result repeatedly at slightly
different times.

Math.random() will almost always return a different result for every
call, until after 2^n calls, where n is not necessarily as large as
should be hoped for.

function AllDiff() { return +new Date() + String(Math.random()) }

should never repeat itself, unless Math.random is either unexpectedly
good or bad, or the computer is prodigiously fast.

--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.
Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036)
Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)

[John G Harris]

On Sun, 5 Feb 2012 at 16:47:36, in comp.lang.javascript, Dr J R Stockton
wrote:

>In comp.lang.javascript message <yxqybXCQ...@J.A830F0FF37FB96852AD0
>8924D9443D28E23ED5CD>, Sat, 4 Feb 2012 10:34:56, John G Harris
><jo...@nospam.demon.co.uk> posted:
>
>
>>The example you are looking for is the function that returns the current
>>time. It returns different values at different times, so lacks any
>>Referential transparency.
>
>I know of a constructor which does that; but is it a function?

<snip>

I was thinking of
(new Date()).getTime()
which is a function call, but of a function with an unusual name.

John
--
John Harris

[John G Harris]

On Thu, 2 Feb 2012 at 11:16:50, in comp.lang.javascript, Michael Haufe
(TNO) wrote:

<snip>

>Of course it seems to me
>that at this point you seem more content in attacking my character
>than anything else.

<snip>

I'm merely adopting, temporarily, your style of argument.


Have you now understood the dangers of defining functions on all sets ?

John
--
John Harris