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

Groups > comp.lang.javascript > #19906 > unrolled thread

!0 versus true

Back to article view | Back to comp.lang.javascript

Contents

  !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

Page 1 of 3  [1] 2 3  Next page →

#19906 — !0 versus true

I'm working with some people who write code and minimises it. As ab 
afterthought, I unminimise some of it and worked my way through it.

One thing I found was that the minimiser had converted all instances of 
true to !0.

When I reported it no one thought it an issue as both true and !0 are 
truthy. Should they be concerned?

Andrew Poulos

[toc] | [next] | [standalone]

#19907

Andrew Poulos wrote:
> I'm working with some people who write code and minimises it. As ab
> afterthought, I unminimise some of it and worked my way through it.
>
> One thing I found was that the minimiser had converted all instances of
> true to !0.
>
> When I reported it no one thought it an issue as both true and !0 are
> truthy. Should they be concerned?

It's not just that both are truthy.  !0 is true, by 11.4.9 and 9.2 of
the ECMA-262 5.1 specification.

But there are of course some degenerate cases where this minification
could still bite you.  E.g.:

    var f=function(){return true;};
    ("" + f).substring(19, 20); // => "t"

    var f=function(){return !0;};
    ("" + f).substring(19, 20); // => "!", in most implementations

But if you have this sort of technique in your code, then you'd
probably avoid minification in any case.  I can't see other reasons
for concern.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#19908

Andrew Poulos wrote:

> I'm working with some people who write code and minimises it. As ab
> afterthought, I unminimise some of it and worked my way through it.
> 
> One thing I found was that the minimiser had converted all instances of
> true to !0.
> 
> When I reported it no one thought it an issue as both true and !0 are
> truthy. Should they be concerned?

They should reconsider their approach as they are exchanging a minor 
increase in loading performance against a probably larger reduction of 
runtime performance, adding an operation (“!”) where there does not have to 
be one, just for the sake of two octets less per occurrence (“!0” vs. 
“true”).

They should ask themselves instead why there were so many occurrences of 
”true” in the code in the first place.  If I wrote a minimizer, *that* is 
where I would look first.  For example,

  if (x == true)

and

  if (true == x)

can be minimized to the equivalent, shorter, more efficient

  if (x)

This is easy to find and replace with regular expressions:

  /* if (x) if (y) z; */
  "if (x == true) if (true == y) z;"
    .replace(/([^=])\s*==\s*true\b|\btrue\s*==\s*([^=])/g, "$1$2");

or

  /* if (x) if (y) z; */
  "if (x == true) if (true == y) z;"
    .replace(/([^=])\s*==\s*true\b|\btrue\s*==(?!=)\s*/g, "$1");

or if the minimizer was Perl or PCRE-based, you could use negative 
lookbehind.  (Exceptions for String and RegExp literals not included.)

Same for type-converting comparisons with “false” and negative type-
converting comparisons with “true” and “false”.

-- 
PointedEars

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

[toc] | [prev] | [next] | [standalone]

#19933

On 5/23/13 8:53 AM, Thomas 'PointedEars' Lahn wrote:
> Andrew Poulos wrote:
>
>> I'm working with some people who write code and minimises it. As ab
>> afterthought, I unminimise some of it and worked my way through it.
>>
>> One thing I found was that the minimiser had converted all instances of
>> true to !0.
>>
>> When I reported it no one thought it an issue as both true and !0 are
>> truthy. Should they be concerned?
>
> They should reconsider their approach as they are exchanging a minor
> increase in loading performance against a probably larger reduction of
> runtime performance, adding an operation (“!”) where there does not have to
> be one, just for the sake of two octets less per occurrence (“!0” vs.
> “true”).
>
> They should ask themselves instead why there were so many occurrences of
> ”true” in the code in the first place.  If I wrote a minimizer, *that* is
> where I would look first.  For example,
>
>    if (x == true)
>
> and
>
>    if (true == x)
>
> can be minimized to the equivalent, shorter, more efficient
>
>    if (x)
Yes, but if (x === true) can not be reduced to if (x).

Also, perhaps you're returning true after doing something that succeeded:

if (flibber()) { flub(); return true; }
if (flabber()) { noFlub(); return false; }

In these cases, reducing true and false to !0 and !!0 might make sense.

>
> This is easy to find and replace with regular expressions:
>
>    /* if (x) if (y) z; */
>    "if (x == true) if (true == y) z;"
>      .replace(/([^=])\s*==\s*true\b|\btrue\s*==\s*([^=])/g, "$1$2");
>
> or
>
>    /* if (x) if (y) z; */
>    "if (x == true) if (true == y) z;"
>      .replace(/([^=])\s*==\s*true\b|\btrue\s*==(?!=)\s*/g, "$1");
>
> or if the minimizer was Perl or PCRE-based, you could use negative
> lookbehind.  (Exceptions for String and RegExp literals not included.)
>
> Same for type-converting comparisons with “false” and negative type-
> converting comparisons with “true” and “false”.
>

[toc] | [prev] | [next] | [standalone]

#19936

Daniel Pitts wrote:

> On 5/23/13 8:53 AM, Thomas 'PointedEars' Lahn wrote:
>> Andrew Poulos wrote:
>>> [true minized to !0]
>>
>> They should reconsider their approach as they are exchanging a minor
>> increase in loading performance against a probably larger reduction of
>> runtime performance, adding an operation (“!”) where there does not have
>> to be one, just for the sake of two octets less per occurrence (“!0” vs.
>> “true”).
>>
>> They should ask themselves instead why there were so many occurrences of
>> ”true” in the code in the first place.  If I wrote a minimizer, *that* is
>> where I would look first.  For example,
>>
>>    if (x == true)
>>
>> and
>>
>>    if (true == x)
>>
>> can be minimized to the equivalent, shorter, more efficient
>>
>>    if (x)
> 
> Yes, but if (x === true) can not be reduced to if (x).

Which is precisely why nobody suggested that.
 
> Also, perhaps you're returning true after doing something that succeeded:
> 
> if (flibber()) { flub(); return true; }
> if (flabber()) { noFlub(); return false; }
> 
> In these cases, reducing true and false to !0 and !!0 might make sense.

It does not, for the reasons I have already given.  In particular your 
latter suggestion is utter nonsense, adding *yet* *another* operation where 
does not have to be one (false === !1).

-- 
PointedEars

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

[toc] | [prev] | [next] | [standalone]

#19937

On 5/24/13 12:56 PM, Thomas 'PointedEars' Lahn wrote:
> Daniel Pitts wrote:
>
>> On 5/23/13 8:53 AM, Thomas 'PointedEars' Lahn wrote:
>>> Andrew Poulos wrote:
>>>> [true minized to !0]
>>>
>>> They should reconsider their approach as they are exchanging a minor
>>> increase in loading performance against a probably larger reduction of
>>> runtime performance, adding an operation (“!”) where there does not have
>>> to be one, just for the sake of two octets less per occurrence (“!0” vs.
>>> “true”).
>>>
>>> They should ask themselves instead why there were so many occurrences of
>>> ”true” in the code in the first place.  If I wrote a minimizer, *that* is
>>> where I would look first.  For example,
>>>
>>>     if (x == true)
>>>
>>> and
>>>
>>>     if (true == x)
>>>
>>> can be minimized to the equivalent, shorter, more efficient
>>>
>>>     if (x)
>>
>> Yes, but if (x === true) can not be reduced to if (x).
>
> Which is precisely why nobody suggested that.
>
>> Also, perhaps you're returning true after doing something that succeeded:
>>
>> if (flibber()) { flub(); return true; }
>> if (flabber()) { noFlub(); return false; }
>>
>> In these cases, reducing true and false to !0 and !!0 might make sense.
>
> It does not, for the reasons I have already given.  In particular your
> latter suggestion is utter nonsense, adding *yet* *another* operation where
> does not have to be one (false === !1).

Yup, I wasn't thinking, !1 does work better.

In any case, worrying about adding a negation operation is silly on 
modern systems. Even lowly smart phones shouldn't have a problem with 
that.  Unless of course you're running a tight loop around some code 
which does that, in which case you might want to hand optimize the 
minified output, or avoid minifying that section at all.

[toc] | [prev] | [next] | [standalone]

#19939

Daniel Pitts wrote:

> On 5/24/13 12:56 PM, Thomas 'PointedEars' Lahn wrote:
>> Daniel Pitts wrote:
>>> Also, perhaps you're returning true after doing something that
>>> succeeded:
>>>
>>> if (flibber()) { flub(); return true; }
>>> if (flabber()) { noFlub(); return false; }
>>>
>>> In these cases, reducing true and false to !0 and !!0 might make sense.
>>
>> It does not, for the reasons I have already given.  In particular your
>> latter suggestion is utter nonsense, adding *yet* *another* operation
>> where does not have to be one (false === !1).
> 
> Yup, I wasn't thinking, !1 does work better.
> 
> In any case, worrying about adding a negation operation is silly on
> modern systems.  Even lowly smart phones shouldn't have a problem with
> that.

Wishful thinking, as expected.

> Unless of course you're running a tight loop around some code

A minimizer cannot know how oftena certain line of code is executed.  Adding 
unnecessary complexity to a program when it should have removed it, is a 
*failure*.

> which does that, in which case you might want to hand optimize the
> minified output, or avoid minifying that section at all.

Just because junk code can run faster on occasion does not make it proper 
code.  Check your assumptions.

And trim your quotes.

-- 
PointedEars

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

[toc] | [prev] | [next] | [standalone]

#19945

On Fri, 24 May 2013 12:17:28 -0700, Daniel Pitts wrote:

> Yes, but if (x === true) can not be reduced to if (x).

How about if(x===!0)

if "!0" is identical to "true" then the test "x===true" is identical to 
the test "x===!0"

Where I use "is identical to" in the sense of "===", whereas I would use 
"is equivalent to" in the sense of "=="

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#19952

Denis McMahon wrote:

> On Fri, 24 May 2013 12:17:28 -0700, Daniel Pitts wrote:
>> Yes, but if (x === true) can not be reduced to if (x).
> 
> How about if(x===!0)

I think that was the point of the comment.  However, it is not a good idea.  
This is not just an equivalent expression.  Since we must not assume 
optimization, it includes an *additional operation* *each* time this 
statement is executed.  For what?  Two octets less loaded the *one* time it 
is loaded – a time savings of 0.3 ms in the *worst* case (56k dial-up 
modem)?

<http://samizdat.mines.edu/howto/HowToBeAProgrammer.html#id2789469>

> if "!0" is identical to "true" then the test "x===true" is identical to
> the test "x===!0"

And +!1 is equivalent to 0.  We still write only 0; not because it is 
shorter, but because it is *less complex*, i.e. *faster*.

> Where I use "is identical to" in the sense of "===", whereas I would use
> "is equivalent to" in the sense of "=="

Making up your private terminology is not helpful.  An *expression* is 
/equivalent/ to another *expression* if both expressions are evaluated to 
the same value under the same conditions; one expression can be exchanged 
with the other without affecting the outcome of expressions in which they 
are used.  A *value* is /identical/ to another *value* if both values are 
the same.

-- 
PointedEars

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

[toc] | [prev] | [next] | [standalone]

#19958

Thomas 'PointedEars' Lahn wrote:
> Denis McMahon wrote:

>> if "!0" is identical to "true" then the test "x===true" is identical to
>> the test "x===!0"
>
> And +!1 is equivalent to 0.  We still write only 0; not because it is
> shorter, but because it is *less complex*, i.e. *faster*.
>
>> Where I use "is identical to" in the sense of "===", whereas I would use
>> "is equivalent to" in the sense of "=="
>
> Making up your private terminology is not helpful.

ACK

>                                                     An *expression* is
> /equivalent/ to another *expression* if both expressions are evaluated to
> the same value under the same conditions; one expression can be exchanged
> with the other without affecting the outcome of expressions in which they
> are used. [ ... ]

But this is less clear to me, at least as to its practical
implications.  Because of the ability to retrieve (at least an
approximation of) the source of a function as a string from within
running code, expressions that are not character-for-character
identical can cause different behaviors in a program, even though
meeting your definition above.  This makes me suspect that your
definition doesn't really capture what one would want it to capture:

    var f=function(){return 0;};
    alert(("" + f).substring(19, 20));

versus:

    var f=function(){return +!1;};
    alert(("" + f).substring(19, 20));

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 "+".

  -- Scott

[toc] | [prev] | [next] | [standalone]

#19959

Scott Sauyet wrote on 26 mei 2013 in comp.lang.javascript:

>     var f=function(){return 0;};
>     alert(("" + f).substring(19, 20));
> 
> versus:
> 
>     var f=function(){return +!1;};
>     alert(("" + f).substring(19, 20));
> 
> 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 "+".
> 

Your grave programming error shows here, Scott:

<script type='text/javascript'>

    function f2(){return +0007;};
    document.write( f2 );

    	document.write('<br><br>');

    function f2(){return +0007;};
    document.write( f2() );

</script>


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

[toc] | [prev] | [next] | [standalone]

#19960

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>>                                                     An *expression* is
>> /equivalent/ to another *expression* if both expressions are evaluated to
>> the same value under the same conditions; one expression can be exchanged
>> with the other without affecting the outcome of expressions in which they
>> are used. [ ... ]
> 
> But this is less clear to me, at least as to its practical
> implications.  Because of the ability to retrieve (at least an
> approximation of) the source of a function as a string from within
> running code, expressions that are not character-for-character
> identical can cause different behaviors in a program, even though
> meeting your definition above.  This makes me suspect that your
> definition doesn't really capture what one would want it to capture:
> 
>     var f=function(){return 0;};
>     alert(("" + f).substring(19, 20));
> 
> versus:
> 
>     var f=function(){return +!1;};
>     alert(("" + f).substring(19, 20));
> 
> 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).

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.

If you were to consider the function instead, you would find that

  f() === 0

in both cases.  That is, the expressions “0” and “+!1” *are* *equivalent* 
because they are evaluated to the same (*identical*) value, (+)0 under the 
same (here: all) conditions.  As a result, the functions returning that 
value are equivalent, i.e. one can be replaced with the other in the same 
expression without affecting the outcome (“true”) of evaluating the 
expression in which it is used.  (It is that equivalence why refactoring and 
minimizers work.)

HTH

-- 
PointedEars

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

[toc] | [prev] | [next] | [standalone]

#19962

Thomas 'PointedEars' Lahn wrote:
> Scott Sauyet wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>>                                                     An *expression* is
>>> /equivalent/ to another *expression* if both expressions are evaluated to
>>> the same value under the same conditions; one expression can be exchanged
>>> with the other without affecting the outcome of expressions in which they
>>> are used. [ ... ]
>
>> But this is less clear to me, at least as to its practical
>> implications.  Because of the ability to retrieve (at least an
>> approximation of) the source of a function as a string from within
>> running code, expressions that are not character-for-character
>> identical can cause different behaviors in a program, even though
>> meeting your definition above.  This makes me suspect that your
>> definition doesn't really capture what one would want it to capture:
>
>>     var f=function(){return 0;};
>>     alert(("" + f).substring(19, 20));
>
>> versus:
>
>>     var f=function(){return +!1;};
>>     alert(("" + f).substring(19, 20));
>
>> 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>

> 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.

I was not expressing confusion.  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.


> If you were to consider the function instead, you would find that
>
>   f() === 0
>
> in both cases.  That is, the expressions “0” and “+!1” *are* *equivalent*
> because they are evaluated to the same (*identical*) value, (+)0 under the
> same (here: all) conditions.  As a result, the functions returning that
> value are equivalent, i.e. one can be replaced with the other in the same
> expression without affecting the outcome (“true”) of evaluating the
> expression in which it is used.  (It is that equivalence why refactoring and
> minimizers work.)

And my example shows one limitations of minimizers (and in fact in all
refactorings) in languages that allow programs access to their own
source code.

Here you simply restate your definition.  It's a reasonable-seeming
one.  But it has a serious flaw, which might be stated like this: two
programs which differ only in that a single expression in one has been
replaced by an equivalent expression in the other do not necessarily
exhibit the same behavior under the same conditions.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#19967

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Scott Sauyet wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> An *expression* is
>>>> /equivalent/ to another *expression* if both expressions are evaluated
>>>> to the same value under the same conditions; one expression can be
>>>> exchanged with the other without affecting the outcome of expressions
>>>> in which they are used. [ ... ]
>>> 
>>> But this is less clear to me, at least as to its practical
>>> implications.  Because of the ability to retrieve (at least an
>>> approximation of) the source of a function as a string from within
>>> running code, expressions that are not character-for-character
>>> identical can cause different behaviors in a program, even though
>>> meeting your definition above.  This makes me suspect that your
>>> definition doesn't really capture what one would want it to capture:
>>> 
>>> var f=function(){return 0;};
>>> alert(("" + f).substring(19, 20));
>>> 
>>> versus:
>>> 
>>> var f=function(){return +!1;};
>>> alert(("" + f).substring(19, 20));
>>> 
>>> 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”.
 
>> 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.
 
> I was not expressing confusion.

But evidently you *are* 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.
 
>> If you were to consider the function instead, you would find that
>>
>>   f() === 0
>>
>> in both cases.  That is, the expressions “0” and “+!1” *are* *equivalent*
>> because they are evaluated to the same (*identical*) value, (+)0 under
>> the same (here: all) conditions.  As a result, the functions returning
>> that value are equivalent, i.e. one can be replaced with the other in the
>> same expression without affecting the outcome (“true”) of evaluating the
>> expression in which it is used.  (It is that equivalence why refactoring
>> and minimizers work.)
> 
> And my example shows one limitations of minimizers (and in fact in all
> refactorings) in languages that allow programs access to their own
> source code.

No, it does not.  Minimizing and all refactoring are operations on the 
original *source code*.  You are confusing the expressions with the values 
created from them.
 
> Here you simply restate your definition.

I have used your example to show that “my” definition is correct.

> It's a reasonable-seeming one.

It is a/the correct one.

> But it has a serious flaw, which might be stated like this: two programs
> which differ only in that a single expression in one has been replaced by
> an equivalent expression in the other do not necessarily exhibit the same
> behavior under the same conditions.

No, you have just learned the difference between an expression and its 
string representation, and the difference between functional equivalence and 
value-equivalence.

BTW, this is beyond the scope of this newsgroup.

-- 
PointedEars

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

[toc] | [prev] | [next] | [standalone]

#19984

Thomas 'PointedEars' Lahn wrote:
>Scott Sauyet wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Scott Sauyet wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> An *expression* is
>>>>> /equivalent/ to another *expression* if both expressions are evaluated
>>>>> to the same value under the same conditions; one expression can be
>>>>> exchanged with the other without affecting the outcome of expressions
>>>>> in which they are used. [ ... ]
>
>>>> But this is less clear to me, at least as to its practical
>>>> implications.  Because of the ability to retrieve (at least an
>>>> approximation of) the source of a function as a string from within
>>>> running code, expressions that are not character-for-character
>>>> identical can cause different behaviors in a program, even though
>>>> meeting your definition above.  This makes me suspect that your
>>>> definition doesn't really capture what one would want it to capture:
>
>>>> var f=function(){return 0;};
>>>> alert(("" + f).substring(19, 20));
>
>>>> versus:
>
>>>> var f=function(){return +!1;};
>>>> alert(("" + f).substring(19, 20));
>
>>>> 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.


>>> 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.


>> 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 am not 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.


>>> If you were to consider the function instead, you would find that
>
>>>   f() === 0
>
>>> in both cases.  That is, the expressions “0” and “+!1” *are* *equivalent*
>>> because they are evaluated to the same (*identical*) value, (+)0 under
>>> the same (here: all) conditions.  As a result, the functions returning
>>> that value are equivalent, i.e. one can be replaced with the other in the
>>> same expression without affecting the outcome (“true”) of evaluating the
>>> expression in which it is used.  (It is that equivalence why refactoring
>>> and minimizers work.)
>
>> And my example shows one limitations of minimizers (and in fact in all
>> refactorings) in languages that allow programs access to their own
>> source code.
>
> No, it does not.  Minimizing and all refactoring are operations on the
> original *source code*.  You are confusing the expressions with the values
> created from them.

No, I am noting that in some implementations (in fact in most modern
browsers) a program has access to portions of that original source
code, or at least to approximations thereof.  I think perhaps you've
been missing the point that my example included the `alert` statement
as part of the same program being minified.

If a minimizer ran against the following two-line program:

    var f=function(){return +!1;};
    alert(("" + f).substring(19, 20));

by your definition, it should be allowed to create this one:

    var f=function(){return 0;};
    alert(("" + f).substring(19, 20));

But the second program has observably different behavior than the
first.


>> Here you simply restate your definition.
>
> I have used your example to show that “my” definition is correct.

Correct according to what standards?  I'm a mathematician by training;
I'm used to terms being defined for convenience.  But there is a
question of the utility of a definition.  I'm not sure there is any
better definition of "equivalent expression", but I'm suggesting that
in the context of Javascript (or ECMAScript implementation, if you
prefer) the notion of "equivalent expression" is not nearly as useful
as it might be in other languages.  If equivalent expressions cannot
be freely substituted without possibly changing the behavior of a
program, then what practical use is there of knowing that the
expressions are equivalent?



>> It's a reasonable-seeming one.
>
> It is a/the correct one.

References, please?


>> But it has a serious flaw, which might be stated like this: two programs
>> which differ only in that a single expression in one has been replaced by
>> an equivalent expression in the other do not necessarily exhibit the same
>> behavior under the same conditions.
>
> No, you have just learned the difference between an expression and its
> string representation, and the difference between functional equivalence and
> value-equivalence.

No, I quite understood that difference.  I was trying to point out
that the string representations of some expressions are, for better or
for worse, accessible from within code.

The question is whether you've learned anything from this.  Do you
claim that the two programs above will have the same behavior?  Or can
you agree that by your definition, equivalent expressions cannot be
freely substituted in programs without risking a change in that
program's behavior?


> BTW, this is beyond the scope of this newsgroup.

For heaven's sake, why?

We are discussing a feature of ES languages, and how that might differ
from certain other languages.  Why in the world would that be out-of-
bounds?

  -- Scott

[toc] | [prev] | [next] | [standalone]

#19987

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.

[toc] | [prev] | [next] | [standalone]

#19991

Thomas 'PointedEars' Lahn wrote:
> Scott Sauyet wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Scott Sauyet wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Scott Sauyet wrote:

>>>>> 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.

And with that, I'll abandon this to the "Scroll position detection"
thread.

:-)


>>>>> 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.

Of course I am.  That's the whole point.  You can't be blind enough
not to recognize this after all the different ways I've phrased it so
far.  Various implementations allow us to use functions this way.  The
fact that you can do so means that two programs differing only by a
single expression can have different behavior even though the two
expressions are equivalent.

Do you agree with that or not?  If not, can you explain why?


>           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.

Please read more carefully.  I never claimed that.


> Which was what I had referred to in “my” definition (I put that in quotes
> deliberately).

And, if you haven't heard it yet, I'm explaining that this definition
is not as useful in a language which allows programmatic access to the
source code of certain expressions.


> 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).

You seem to have things in the wrong order.  I'm not trying to
demonstrate any exception to your definition.  I'm trying to show that
the definition you presented offers little of use when discussing ES
implementations.


>                      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.

Yes they would.  But in many modern implementations, this is not how
it works.  The problem is not that it always happens.  The problem is
that it could happen.  I've tested the following two links in five
relatively modern browsers:

    <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.  I understand
that the specification does not insist on precisely this behavior.
But the specification *allows* it.


>>>> 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'm afraid you have that backwards.  Or do you assert that all
specification-conforming browsers *should* yield identical behavior
for the two programs mentioned above?



>> 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.

No, I'm afraid you haven't been reading very carefully.


>>>> 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.

Do you even know how to read?

This is what I said upon joining this thread:

| This makes me suspect that your definition doesn't really
| capture what one would want it to capture

I have been arguing that your definition lacks utility.



>>> 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.

If that were all we were discussing, it would still be relevant to
this group, as it has a bearing on how the language(s) under
discussion behave(s).  But I've brought in other points beyond formal
equivalence that have little to do with mathematics, computer science,
or linguistics.  It is certainly relevant.


> 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).

And this latter point is irrelevant to this ng?


>> 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.

You seem to be determined to discard what I'm discussing, but I am
talking about a feature of languages such as JavaScript, JScript, and
the like, not usually available in most languages I've used.  How many
programming languages allow direct programmatic access to the source
code of their functions?

This is quite relevant to this group.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#19993

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Scott Sauyet wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Scott Sauyet wrote:
>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>> 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.
> 
> Of course I am.  That's the whole point.

You do not have a point.  You are misinterpreting “my” definition of 
(value-)equivalence of an expression to include “string representations of 
functions in which this expression occurs”, so that you can claim that the 
definition would not universally apply although it never was claimed that it 
applied universally.  This is the strawman argument that I am talking about.

In addition, you are ignoring that string representations of functions are 
implementation-dependent in the first place, thus not suited to support your 
point if you had one.

> You can't be blind enough not to recognize this after all the different
> ways I've phrased it so far. 

“When did you stop beating your wife?”

> Various implementations allow us to use functions this way.

Such as?

> The fact that you can do so means that two programs differing only by a
> single expression can have different behavior even though the two
> expressions are equivalent.

No, it means that ECMAScript programs which rely on function serialization 
are deeply flawed, which really is old news.
 
> Do you agree with that or not?

I do not agree with your knee-jerk interpretation of what I wrote, …

> If not, can you explain why?

… because you are ignoring the context in which I wrote it.

>> 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.
> 
> Please read more carefully.  I never claimed that.

You claimed, while ignoring the difference, that therefore “my” definition 
was not useful.  As for reading carefully, you should have read the 
following paragraph more carefully.
 
>> Which was what I had referred to in “my” definition (I put that in quotes
>> deliberately).
> 
> And, if you haven't heard it yet, I'm explaining that this definition
> is not as useful in a language which allows programmatic access to the
> source code of certain expressions.

Which is wrong, caused by your proceeding from a false premise.  Ex falso 
quodlibet.

>> 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).
> 
> You seem to have things in the wrong order.

Apparently you are unable to read statements in context, and I am getting 
tired pointing that out to you.

> I'm not trying to demonstrate any exception to your definition.

Yes, you are.  You have (mis)used function serialization to demonstrate an 
exception to it where actually none exists.  The function itself is a 
context that *you* have added.

> I'm trying to show that the definition you presented offers little of use
> when discussing ES implementations.

Which is still wrong.

> [tl;dr]

-- 
PointedEars

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

[toc] | [prev] | [next] | [standalone]

#19996

Thomas 'PointedEars' Lahn wrote:
>Scott Sauyet wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Scott Sauyet wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Scott Sauyet wrote:
>>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>>> 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.

>> Of course I am.  That's the whole point.

> You do not have a point.  You are misinterpreting “my” definition of
> (value-)equivalence of an expression to include “string representations of
> functions in which this expression occurs”, so that you can claim that the
> definition would not universally apply although it never was claimed that it
> applied universally.  This is the strawman argument that I am talking about.
>
> In addition, you are ignoring that string representations of functions are
> implementation-dependent in the first place, thus not suited to support your
> point if you had one.

Again, you are twisting things.  I did not in any way suggest that
your definition included string representations of the functions.  I
said simply that as a definition the one you presented means little in
the languages most discussed here.  Since that definition cannot be
reliably used to transform arbitrary programs into other ones with the
same behavior, the definition adds nothing of value to the discourse.


>> You can't be blind enough not to recognize this after all the different
>> ways I've phrased it so far.
>
> “When did you stop beating your wife?”

Or perhaps you can.  "I stopped long before I started."


>> Various implementations allow us to use functions this way.
>
> Such as?

Recent versions of SpiderMonkey, V8, and Chakra, to name a few.


>> The fact that you can do so means that two programs differing only by a
>> single expression can have different behavior even though the two
>> expressions are equivalent.
>
> No, it means that ECMAScript programs which rely on function serialization
> are deeply flawed, which really is old news.

So is the definition you've been defending only worthwhile when
programmers eschew function serialization?



>> Do you agree with that or not?
>
> I do not agree with your knee-jerk interpretation of what I wrote, …

It was a simple question.  I said that "two programs differing only by
a
single expression can have different behavior even though the two
expressions are equivalent."  Again, do you agree with that?


>> If not, can you explain why?
>
> … because you are ignoring the context in which I wrote it.

No, I'm asking if you agree with a statement I made.  Nothing you
wrote has any bearing on it.  Can you give (and defend) a yes or no
answer to that question?


>>> 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.
>
>> Please read more carefully.  I never claimed that.
>
> You claimed, while ignoring the difference, that therefore “my” definition
> was not useful.

And I still claim it.  I'm glad you finally understand.  Do you
understand the basis for my argument?  Do you have an actual
counterargument?


>                  As for reading carefully, you should have read the
> following paragraph more carefully.
>
>>> Which was what I had referred to in “my” definition (I put that in quotes
>>> deliberately).

I did ask earlier for references.  Until shown otherwise, I have no
problem attributing this definition to you.  Is that what you're
complaining about?


>> And, if you haven't heard it yet, I'm explaining that this definition
>> is not as useful in a language which allows programmatic access to the
>> source code of certain expressions.
>
> Which is wrong, caused by your proceeding from a false premise.  Ex falso
> quodlibet.

Except that I should have said "in an implementation which allows...",
what false premise do you see?


>>> 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).
>
>> You seem to have things in the wrong order.
>
> Apparently you are unable to read statements in context, and I am getting
> tired pointing that out to you.

Funny, I thought I was the one pointing that out to you.  Ad nauseum.


>> I'm not trying to demonstrate any exception to your definition.
>
> Yes, you are.  You have (mis)used function serialization to demonstrate an
> exception to it where actually none exists.  The function itself is a
> context that *you* have added.

No.  What does it take to make you realize that I'm accepting entirely
your definition of equivalent expressions, and proceeding to show that
it cannot be reliably used to alter a program by substituting one
expression for an equivalent one without risking a change in the
behavior of the program?

I did not try to demonstrate an exception to the equivalence of
expressions.  The different behavior I presented was in an entirely
different statement of the program than the one where the expression
substitution occurred.  It is no exception to your definition.

If you're willing to say that the definition of equivalent expressions
you presented is consistent and coherent but still risky for any
automated program manipulation in many modern ES implementations, then
we'd be in agreement.  But it sounds as though you disagree.




>> I'm trying to show that the definition you presented offers little of use
>> when discussing ES implementations.
>
> Which is still wrong.

So how do you propose it gets used?


>> [tl;dr]

Yeah, I'm getting pretty tired of this too.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#20003

On Mon, 27 May 2013 17:12:59 -0700 (PDT), Scott Sauyet
<scott.sauyet@gmail.com> 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.

You are saying that when  f()  and  g()  are 'equivalent' expressions
then  f.toString()  should be 'equivalent' to  g.toString()  for
equivalence to be a useful concept.

Why? After all, you wouldn't expect the expressions  f  and  g  to be
the same : they evaluate to references to different function objects.
These objects can be given different properties by the program without
changing the values returned by f() and g().

The equivalence of expressions is not the same as the equivalence of
objects.

  John

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web