Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <44279053.ug29IgtNvP@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Thu, 02 Feb 2012 23:09:57 +0100 User-Agent: KNode/4.4.11 Content-Transfer-Encoding: 8Bit Subject: Re: Comparing arraies Newsgroups: comp.lang.javascript References: <8dc6b834-cd20-47a5-a085-f4d5e4402c38@c13g2000yqk.googlegroups.com> <1634287.nPeGqDzKj4@PointedEars.de> <1946200.aqSPkdTlGX@PointedEars.de> <1660771.jP65nafYdu@PointedEars.de> <7a3a197b-9f8c-45a1-92aa-22a3a5d0b297@t15g2000yqi.googlegroups.com> <3325601.CWPS83hRNz@PointedEars.de> <336bb7d2-5ab8-46ea-88a3-2e5e47cb9663@o20g2000yqh.googlegroups.com> <1949843.mKqTvaHIzj@PointedEars.de> <6fbfd423-02ec-49a8-a3a2-345e9271e74c@k28g2000yqn.googlegroups.com> Followup-To: comp.lang.javascript MIME-Version: 1.0 Lines: 121 NNTP-Posting-Date: 02 Feb 2012 23:09:57 CET NNTP-Posting-Host: 1cc6d435.newsspool4.arcor-online.net X-Trace: DXC=b8?^XE@kIdNj7E:bke<5HF4IUK 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: > > 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] [2] [3] "Google Tech Talk – Changes to JavaScript, Part 1: EcmaScript 5", with Mark Miller, Waldemar Horwat, and Mike Samuel. -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, (2004)