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


Groups > comp.lang.javascript > #19987

Re: !0 versus true

Message-ID <5260436.L7RB4VL119@PointedEars.de> (permalink)
From Thomas 'PointedEars' Lahn <PointedEars@web.de>
Organization PointedEars Software (PES)
Date 2013-05-27 23:30 +0200
Subject Re: !0 versus true
Newsgroups comp.lang.javascript
References (5 earlier) <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>

Show all headers | View raw


Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Scott Sauyet wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Scott Sauyet wrote:
>>>>> Although the expressions `0` and `+!1` should be considered equivalent
>>>>> by such a definition, these two short programs have different
>>>>> behaviors in many modern ES implementation, the first alerting "0",
>>>>> the second alerting "+".
>>>> If that.  The string representation of functions, that is, the return
>>>> value of Function.prototype.toString() for a Function instance as its
>>>> “this” value, is *implementation-dependent* (ES 5.1, §15.3.4.2).
>>> Correct, although it's scheduled to become more standardized in ES 6:
>>> <http://wiki.ecmascript.org/doku.php?id=harmony:function_to_string>
>> This is interesting, but does not justify the statement “is scheduled to
>> become more standardized”.
> 
> You're right.  I was under the impression that this was included in
> the latest (2013-05-14) Draft Specification for ES.next (Ecma-262
> Edition 6).  But §15.3.3.2 still contains the old "implementation-
> dependent" language.

It would still only be a Draft Specification even if it were in there.

>>>> Your confusion stems from the fact that you are proceeding from a false
>>>> assumption.  It is _not_ the function that is used in your example, but
>>>> a string representation of the function.
>>
>>> I believe I said as much.
>>
>> No, you did not.
> 
> Yes, I did too.
> 
> I said:
> 
> | Because of the ability to retrieve (at least an approximation of)
> | the source of a function as a string from within running code...
> 
> and you quoted it twice so far in this thread.

But this is a different context.  You are using the functions as a value (in 
particular, their string representations), not the return value of the 
functions.  Therefore, your examples do not show that the expression that is 
evaluated to the return value of the one function is not equivalent to the 
expression that is evaluated to the return value of the other function.  
Which was what I had referred to in “my” definition (I put that in quotes 
deliberately).

IOW, you have only showed that the functions thus created are not value-
equivalent with regard to their string representations (and nobody had 
claimed they were).  That is, if the implementation-dependent string 
representations could have showed that.  For example, it would be standards 
compliant if the content of the function body were not contained in the 
representation at all because there is no Specification requirement for 
that.  The string representations would not be distinguishable then, and the 
two functions would not only be functional equivalent, but also value-
equivalent with regard to their string representations.

>>> I was not expressing confusion.
>>
>> But evidently you *are* confused.
> 
> Have you never, even once, considered the possibility that someone who
> disagrees might understand the subject in as much depth as you do and
> still have reached a different conclusion?

I have.  But evidently you have not understood this subject (in as much 
depth as I have).

> I am not confused.

Well, you have been confusing different contexts and concepts.  So it is 
fair to say that you are at least a bit confused.

>>> I was noting that your definition of equivalence sounds as though it
>>> would imply that two programs that differed only by a difference of two
>>> expressions that were equivalent would in fact have identical behavior,
>>> but that this is not actually true.  I realize you didn't claim this.
>>> But the fact that it's not true means that the definition has less
>>> utility than it seems.
>>
>> No, it means that you are trying (and failing) to use a strawman
>> argument.
> 
> No, I am making a fairly simple point:  Even though two expressions
> are equivalent under your definition, one cannot count on being able
> to substitute one for the other in all programs without changing
> behavior.  This to me means that the definition is less useful than it
> first sounds.  [fallacy]

But nobody except you has claimed that your interpretation applies there.  
That is why yours *is* a strawman argument.

>> BTW, this is beyond the scope of this newsgroup.
> 
> For heaven's sake, why?

Because equivalence as it is discussed here is not specific to ECMAScript; 
it is a subject of mathematics, computer science, and linguistics within the 
domain of formal languages.  It can be understood as an equivalent 
translation where we would exchange one word (e.g., “+!1”) with another word 
(e.g., “0”) without the phrase changing its meaning, because the first word 
is defined to be a compound word that has the same meaning as the second 
(non-compound) word.

Obviously there is an intrinsic difference between using the original phrase 
(i.e., using the string representation of a function) and using the 
translated phrase (i.e., calling that function and using its return value).

> We are discussing a feature of ES languages, […]

No, actually we are not.  We just happen to discuss this general concept in 
the context of ECMAScript and its implementations.

-- 
PointedEars

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

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

!0 versus true Andrew Poulos <ap_prog@hotmail.com> - 2013-05-23 23:31 +1000
  Re: !0 versus true Scott Sauyet <scott.sauyet@gmail.com> - 2013-05-23 07:58 -0700
  Re: !0 versus true Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-23 17:53 +0200
    Re: !0 versus true Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-05-24 12:17 -0700
      Re: !0 versus true Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-24 21:56 +0200
        Re: !0 versus true Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-05-24 13:13 -0700
          Re: !0 versus true Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-24 22:23 +0200
      Re: !0 versus true Denis McMahon <denismfmcmahon@gmail.com> - 2013-05-24 22:08 +0000
        Re: !0 versus true Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-25 07:00 +0200
          Re: !0 versus true Scott Sauyet <scott.sauyet@gmail.com> - 2013-05-25 20:04 -0700
            Re: !0 versus true "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2013-05-26 11:07 +0200
            Re: !0 versus true Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-26 13:11 +0200
              Re: !0 versus true Scott Sauyet <scott.sauyet@gmail.com> - 2013-05-26 13:28 -0700
                Re: !0 versus true Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-27 12:07 +0200
                Re: !0 versus true Scott Sauyet <scott.sauyet@gmail.com> - 2013-05-27 11:27 -0700
                Re: !0 versus true Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-27 23:30 +0200
                Re: !0 versus true Scott Sauyet <scott.sauyet@gmail.com> - 2013-05-27 17:12 -0700
                Re: !0 versus true Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-28 02:40 +0200
                Re: !0 versus true Scott Sauyet <scott.sauyet@gmail.com> - 2013-05-27 20:29 -0700
                Re: !0 versus true John Harris <niam@jghnorth.org.uk.invalid> - 2013-05-28 15:38 +0100
                Re: !0 versus true Scott Sauyet <scott.sauyet@gmail.com> - 2013-05-28 08:32 -0700
                Re: !0 versus true Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-28 21:14 +0200
                Re: !0 versus true Scott Sauyet <scott.sauyet@gmail.com> - 2013-05-28 15:38 -0700
                Re: !0 versus true Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-29 13:20 +0200
                Re: !0 versus true Scott Sauyet <scott.sauyet@gmail.com> - 2013-05-29 06:37 -0700
                Re: !0 versus true Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-29 16:28 +0200
                Re: !0 versus true Scott Sauyet <scott.sauyet@gmail.com> - 2013-05-29 13:32 -0700
                Re: !0 versus true Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-29 23:34 +0200
                Re: !0 versus true Scott Sauyet <scott.sauyet@gmail.com> - 2013-05-30 06:30 -0700
                Re: !0 versus true John Harris <niam@jghnorth.org.uk.invalid> - 2013-05-29 17:33 +0100
                Re: !0 versus true Scott Sauyet <scott.sauyet@gmail.com> - 2013-05-29 11:34 -0700
                Re: !0 versus true John Harris <niam@jghnorth.org.uk.invalid> - 2013-05-31 10:22 +0100
                Re: !0 versus true Christoph Becker <cmbecker69@gmx.de> - 2013-05-31 13:04 +0200
                Re: !0 versus true Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-31 18:13 +0200
                Re: !0 versus true Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-31 18:16 +0200
                Re: !0 versus true Scott Sauyet <scott.sauyet@gmail.com> - 2013-05-31 07:25 -0700
  Re: !0 versus true imma harper <immaterial_uk@yahoo.co.uk> - 2013-05-31 09:46 -0700
    Re: !0 versus true Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-05-31 21:38 +0200
    Re: !0 versus true John Harris <niam@jghnorth.org.uk.invalid> - 2013-06-01 17:37 +0100
  Re: !0 versus true Dr J R Stockton <reply1300@merlyn.demon.co.uk.invalid> - 2013-06-02 21:03 +0100
    Re: !0 versus true Scott Sauyet <scott.sauyet@gmail.com> - 2013-06-03 04:45 -0700
      Re: !0 versus true Dr J R Stockton <reply1300@merlyn.demon.co.uk.invalid> - 2013-06-04 17:23 +0100

csiph-web