Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!ecngs!feeder2.ecngs.de!newsfeeder.ewetel.de!eweka.nl!lightspeed.eweka.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Content-Type: text/plain; charset="UTF-8"
Message-ID: <10880935.qUOYKYk0ac@PointedEars.de>
From: Thomas 'PointedEars' Lahn <PointedEars@web.de>
Reply-To: Thomas 'PointedEars' Lahn <usenet@PointedEars.de>
Organization: PointedEars Software (PES)
Date: Wed, 29 May 2013 13:20:48 +0200
User-Agent: KNode/4.10.2
Content-Transfer-Encoding: 8Bit
X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&.<b';Md8`dH6iqhT)6C^.Px|[=M@7=Ik[_w<%n1Up"LPQNu2m8|L!/3iby{-]A+#YE}Kl{Cw$\U!kD%K}\2jz"QQP6Uqr],./"?;=4v
Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEXTxa4RFk5dUWANED8PFEfy7+MGBiW+n3ZNF/QuAAACaElEQVQ4jVXUwVOcMBQG8Dc7Rc4PUntdWV2uxjDpGaGeozOp1woar4jd5t/v9wLstMwsA/ntlxdCAgUc1hjTc9/JCZfGoo3wG3HdmdAWrIJRHe7GM/TmpY5VFefuVcAkkPbLIaN8rmPmjloyZxgyR3GuJ4K0AGtJ2htz8o7yqikm759fldQXaMpbDzjKAG+8v+AugVTOPO5DOjLvGtUYQwh0CPjnVMyGd+8/GfUB5nLKJDD2aLDh5HYyMDJGDwQIo2ZmZcKbowNmAdB/AzyFhrmF2MHRb0QJJfaAnwGB6orZhoykLzJtGwF/xpYxI1dswomiUj3gTuAIqCn/4C7cULwGNBtwMTk3Y4LfKB5YUaOKBKYtpplm7u0vip8tU1NWWyI/7XdcSuIDoMt6rVHMWT0DbjHPGqDqZVSa6zleLcUTcIKLoMv3ueJluALtAo9B302zPPlrtiVScRdCjXvVh3e3JpYa/jjkuC9N+LrBMlz/eAN4eQijX2EdLo6c5tGGHwLyHFtXk89dDGHwCVhG9T0S/j55AhRZgkMCmUQXJ49TnS1wnQDvw0eAh9ICeMmEFbCnPMFzjAvsWoEWEFdYEx+S0MoUZ1gT1wId8+AF3Bl2OoEu906AUHx5VLw/gXYg/x84loOah/2UYNrgiwSwGO7RfUzVBbx/kgpckumGOi6QirtD6gkLTitbnxNol47S2jVc2vsN5kPqaAHT8uUdAJM4v/DanjYOwmUjWznGfwB7sGtAtor5BgofDuzaRj4kSQAqDakTsKORa3Q3xKi3gE1fhl71KRMqrdZ2AWNNg/YOhQyrVBnb+i+nEg4bsDA+egAAAABJRU5ErkJggg==
Subject: Re: !0 versus true
Newsgroups: comp.lang.javascript
References: <a1Pnt.5879$OS5.4813@newsfe24.iad> <knooc3$qpi$1@dont-email.me> <1639100.PjNAD8PV0k@PointedEars.de> <8f4997a5-cb1c-4d4c-961e-c88226531c6d@cl9g2000vbb.googlegroups.com> <2307387.pZyV4EZjM8@PointedEars.de> <7bbd3b78-c201-4ac4-98b6-77a3d270c807@fv8g2000vbb.googlegroups.com> <2788472.6QvGpzPONO@PointedEars.de> <ed180bb2-f6be-48dc-941a-adb647bd9b6c@h5g2000vbg.googlegroups.com> <5260436.L7RB4VL119@PointedEars.de> <eba22a46-75ad-4d8f-8cf3-e1dfbaa28743@c7g2000vbv.googlegroups.com> <uaf9q855bh9uri9q6o10oa2oqi7n6lp3r7@4ax.com> <025995e5-77c4-42e0-9c2d-60607ed970e9@2g2000yqr.googlegroups.com> <3158186.8TiyjIphOr@PointedEars.de> <682ad042-58a6-47da-9540-76d8b09f5592@l5g2000vbn.googlegroups.com>
Supersedes: <15400572.FWdijOjfvQ@PointedEars.de>
MIME-Version: 1.0
Lines: 164
NNTP-Posting-Date: 29 May 2013 13:20:49 CEST
NNTP-Posting-Host: 10cf4e35.newsspool1.arcor-online.net
X-Trace: DXC=BCm>GjXnM4B[kmHKHnaEnMic==]BZ:afN4Fo<]lROoRAnkgeX?EC@@@g^WmZX^PGjCDZm8W4\YJNLb@mF9jNikdE7a5\<`>]gfNbl65]>_81JL
X-Complaints-To: usenet-abuse@arcor.de
Xref: csiph.com comp.lang.javascript:20031

[Cancel & Supersedes]

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Scott Sauyet wrote:
>>> John Harris wrote:
>>>> Scott Sauyet wrote:
>>>> <snip>
>>>>> <http://scott.sauyet.com/Javascript/Demo/2013-05-27a/>
>>>>> <http://scott.sauyet.com/Javascript/Demo/2013-05-27b/>
>>>>> 
>>>>> In all browsers I tested, the programs displayed different behavior,
>>>>> even though the two programs are identical except that one expression
>>>>> has been replaced by an equivalent one in the second.
>>>> <snip>
>>>> 
>>>> Name the functions in the two examples f and g to lessen the
>>>> confusion.
>>> 
>>> That would only confuse the point.  The point is that the only
>>> difference between the two programs is the substitution of `0` in the
>>> second for the equivalent `+!1` in the first.  Nonetheless the two
>>> programs have different behavior.  Making an additional change by
>>> changing the name of the function would muddy the waters.
>>
>> You are the one who is muddying the waters here.
>>
>> The point is that you continue to fail to differentiate between
>>
>>   A) an expression
>>
>> and
>>
>>   B) the string representation of the function that contains it.
> 
> No, as I've demonstrated repeatedly, I understand the difference.
> 
> However, even though the two programs I supplied differ only in one
> equivalent expression, they have different behavior.
> 
> Stipulating the definition of equivalent expressions as you've
> presented it, if we define Document A as the one residing at
> 
>     <http://scott.sauyet.com/Javascript/Demo/2013-05-27a/>
> 
> and Document B as the one residing at
> 
>     http://scott.sauyet.com/Javascript/Demo/2013-05-27b/>

How typical of you that you would make this a personal issue.
 
> The argument, in excruciating detail, proceeds as follows:
> 
>  1. Document A and Document B differ only on line 9.
>  2. The difference on line 9 starts at column 29.
>  3. That difference falls inside a client-side program spanning lines
>     7 - 18.  These two distinct programs we will label Program A
>     and Program B, respectively.
>  4. The difference from Program A to Program B can be described as
>     the deletion of the characters "+!1" and the insertion of the
>     character "0".
>  5. At character 29 of line 9, an expression is allowable.
>  6. "+!1" is a legal expression.
>  7. "0" is a legal expression.
>  8. "+!1" and "0" are equivalent expressions.
>  9. Hence Program A and Program B differ only in the substitution of
>     equivalent expressions.
> 10. Loading Document A and Document B into Chrome 27.0.1453.94 (*)
>     yield differing output.
> 11. That differing output is the result of the differences between
>     Program A and Program B.
> 12. Therefore, two programs that differ only in the substitution of
>     equivalent expressions can yield differing output.
> 
> (*) Feel free to substitute another modern browser.
> 
> Can you accept this argument

No (but that is not the reason why I also reject your later interpretation).

> If not, which is the first step you reject?

10.

> And why do you reject it?

There is no guarantee for that.  AISB:

| An implementation-dependent representation of the function is returned.
     ^^^^^^^^^^^^^^^^^^^^^^^^
Several other browsers than Chrome (27.0.1453.94) do support a different 
ECMAScript implementation than Google V8 JavaScript.

The ECMAScript Language Specification allows that the return value does not 
contain the contents of the original /FunctionBody/, and it allows that it 
contains other expressions not found in the original.  The only requirement 
is:

| This representation has the syntax of a /FunctionDeclaration/. 

As I indicated before, a conforming ECMAScript implementation is allowed to 
return

  "function () {}"

both for

  (function a (b) { return !+1; }).toString()

and for

  (function c (d, e) { return 0; }).toString()

because

| 13 Function Definition
| 
| Syntax
| 
| […]
| FunctionExpression :
|   function Identifier_opt ( FormalParameterList_opt ) { FunctionBody }
| 
| […]
| FunctionBody :
|    SourceElements_opt

or, in reduced ABNF:

FunctionExpression = "function" [Identifier] "(" [FormalParameterList] ")" 
"{" [SourceElements] "}"

This means that as for their string representation those two functions might 
or might not be value-equivalent.  But they would still be (weakly) 
functional equivalent, because the expressions leading to their return 
values are (value-)equivalent.  (In this case there would also be strong 
functional equivalence because the function calls cannot have side-effects.)

> From here, it's my *interpretation* that the definition supplied is
> not particularly useful, especially in the context specified by the OP
> of minifiers. […]

And precisely *that* is your fallacy.  To break it down for you:

You are falsely assuming that equivalence must be transitive, even 
universal.  That is, you are assuming that if two expressions in a program 
are equivalent, all functions and all programs containing those expressions 
must be equivalent as well.

You find a corner case (string representation of functions in ECMAScript 
implementations) in which this assumption of yours *might not* be fulfilled, 
and therefore you doubt the usefulness of the *original* definition of 
expression/value-equivalence, in the context of ECMAScript implementations.

Can you see your mistake now?

> [tl;dr]

-- 
PointedEars

Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.