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

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

Re: null and NaN

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: null and NaN Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2015-06-05 00:55 -0300
    Re: null and NaN Robert Heller <heller@deepsoft.com> - 2015-06-05 06:57 -0500
      Re: null and NaN Steven D'Aprano <steve@pearwood.info> - 2015-06-07 18:47 +1000
    Re: null and NaN Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-06-06 08:39 +0200
      Re: null and NaN Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2015-06-06 23:15 -0300
        Re: null and NaN Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-06-07 09:59 +0200
          Re: null and NaN Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2015-06-07 22:30 -0300
            Re: null and NaN Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-06-10 20:48 +0200
              Re: null and NaN Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2015-06-11 10:01 -0300
                Re: null and NaN "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-06-11 15:28 +0200
                  Re: null and NaN Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2015-06-11 11:34 -0300
                    Re: null and NaN "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-06-11 21:07 +0200
                      Re: null and NaN Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2015-06-11 17:29 -0300
                        Re: null and NaN "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-06-11 23:15 +0200

#27987 — Re: null and NaN

On 02/06/2015 14:28, Stefan Ram wrote:
>    Sometimes, it has been questioned whether it was wise to
>    implement
>
> typeof null
> "object"
>

It happens due to a bug in the first version of JS [1].

>    . However, I just became aware that this is echoing a
>    similar case:
>
> typeof NaN
> "number"
>
>    . NaN says its »Not a Number«, yet typeof says it is a
>    number!

This case is something else. I'd rather prefer the joke: "NaN stands for 
Not a NaN" [2].

[1] <http://www.2ality.com/2013/10/typeof-null.html>
[2] 
<http://ariya.ofilabs.com/2014/05/the-curious-case-of-javascript-nan.html>

-- 
Joao Rodrigues

[toc] | [next] | [standalone]

#27990

At Fri, 05 Jun 2015 00:55:31 -0300 Joao Rodrigues <groups_jr-1@yahoo.com.br> wrote:

> 
> On 02/06/2015 14:28, Stefan Ram wrote:
> >    Sometimes, it has been questioned whether it was wise to
> >    implement
> >
> > typeof null
> > "object"
> >
> 
> It happens due to a bug in the first version of JS [1].
> 
> >    . However, I just became aware that this is echoing a
> >    similar case:
> >
> > typeof NaN
> > "number"
> >
> >    . NaN says its »Not a Number«, yet typeof says it is a
> >    number!
> 
> This case is something else. I'd rather prefer the joke: "NaN stands for 
> Not a NaN" [2].

'NaN' is a "feature" of IEEE floating point numbers.  Unlike integers, where 
every possible bit pattern represents a possible integer value (there are 2^32 
bit patterns with a 32-bit value and there are in fact 2^32 possible integers 
that can be represented in a 32-bit integer variable), *some* of the 
bit patterns that are possible do NOT represent a legal floating point 
value.  That is, a 32-bit floating point number DOES NOT have 2^32 possible 
legal values.  Also, with floating point arithmetic, there are operations that 
cannot have a 'legal' result (the result is mathematically 'undefined' for 
various reasons).  For arithmetic operations that result in undefined values 
you get NaN.  Note this is different fron INF (which is a special bit pattern
in the IEEE floating point representation).

JavaScript is a *weakly* typed language. Normally that means that variables
don't have declared types, but instead the *value* of variables have an
associated type, which can change. What is happening here is that the 'object'
is 'typed' as a floating point number (a number in the general sense) because
it is the result of some floating point math operation, like Math.sqrt(-1),
but the result is not a representable floating point value, like the square
root of -1. If one was programming in C, C++, or Java and declared a variable:

float i;

and then computed an floating point value that was not a legal floating point 
number, 

i = sqrt(-1.0);

the variable x would still be a float, and its value would be NaN, since
variable types cannot change in a strongly typed language like C, C++, or
Java. (FORTRAN cleverly solves this specific problem by having a complex type 
and makes no attempt to actually represent the sqrt of -1, but simply assumes 
it and provides a library of functions that dance around the irrational 
values.)



> 
> [1] <http://www.2ality.com/2013/10/typeof-null.html>
> [2] 
> <http://ariya.ofilabs.com/2014/05/the-curious-case-of-javascript-nan.html>
> 

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services
                                                                       

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

#28019

On Fri, 5 Jun 2015 09:57 pm, Robert Heller wrote:

> 'NaN' is a "feature" of IEEE floating point numbers.

No need for the scare-quotes around feature, it actually is a feature. The
IEEE-754 standard brought order to chaos in the numerical computing world,
and NANs were a carefully thought out part of that standard.


> Unlike integers, 
> where every possible bit pattern represents a possible integer value
> (there are 2^32 bit patterns with a 32-bit value and there are in fact
> 2^32 possible integers that can be represented in a 32-bit integer
> variable), *some* of the bit patterns that are possible do NOT represent a
> legal floating point
> value.  That is, a 32-bit floating point number DOES NOT have 2^32
> possible
> legal values.

I wouldn't put it like that. NANs are certainly "legal floating point
values", they're just not numbers.

Out of the 2**32 bit patterns available in a 32-bit float, there are:

* two bit patterns which represent zero
* two bit patterns which represent a result which has overflowed, 
  or an actual mathematically infinite result;
* some large number of bit patterns which represent numbers in
  floating point style;
* and some number of bit patterns which represent error conditions
  or results of mathematically undefined calculations.

making a total of 2**32 valid floats in total (but somewhat less than that
represent actual numbers).


> Also, with floating point arithmetic, there are operations 
> that cannot have a 'legal' result (the result is mathematically
> 'undefined' for
> various reasons).  For arithmetic operations that result in undefined
> values
> you get NaN.  Note this is different fron INF (which is a special bit
> pattern in the IEEE floating point representation).

I agree with this paragraph.

But not the following:

> JavaScript is a *weakly* typed language. Normally that means that
> variables don't have declared types, but instead the *value* of variables
> have an associated type, which can change.

No, you are thinking about the difference between static and dynamic typing.

Static typing: variables themselves have types. E.g. "x" is a float, even if
you haven't assigned a value to x yet.

Dynamic typing: variables are just names, and are not associated with a
type. The name "x" doesn't have a type, but the value assigned to x does:
if you assign x = 1.234, then (the value of) x is a float, and if you
assign x = "foo", then (the value of) x is a string.

Untyped: Usually refers to something like assembly language, where there are
no types at all (except in the programmer's own mind).

There are degrees of typing strength. A strongly typed language enforces
type rules strictly, with no automatic or implied coercions. A weakly typed
language enforces type rules in a lenient manner, with many automatic or
implied coercions. People can argue about the boundaries, but I think most
people will use automatic string conversions as the dividing line. If a
language automatically converts strings to numbers when doing arithmetic,
then the language is weakly typed; if not, then it's strongly typed.

Static/Dynamic, versus Weak/Strong, are independent.

For more, see http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote


> What is happening here is that 
> the 'object' is 'typed' as a floating point number (a number in the
> general sense) because it is the result of some floating point math
> operation, like Math.sqrt(-1), but the result is not a representable
> floating point value, like the square root of -1.

I don't think that's actually what is happening. The OP wrote:

typeof NaN

I think that what happens is that NaN is a literal which evaluates to a
floating point number, just like 1.5 evaluates to the floating point 1.5,
except that NaN returns one of those bit patterns that don't represent a
number. I don't think that there are any objects involved here.

I welcome correction if I am wrong.



> If one was programming 
> in C, C++, or Java and declared a variable:
> 
> float i;
> 
> and then computed an floating point value that was not a legal floating
> point number,
> 
> i = sqrt(-1.0);
> 
> the variable x would still be a float, and its value would be NaN, since
> variable types cannot change in a strongly typed language like C, C++, or
> Java.

> (FORTRAN cleverly solves this specific problem by having a complex 
> type and makes no attempt to actually represent the sqrt of -1, but simply
> assumes it and provides a library of functions that dance around the
> irrational values.)

Fortran is strongly typed like C. If you want to use complex numbers in
Fortran, you have to declare i as a complex number, not a float.



-- 
Steven

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

#28000

Joao Rodrigues wrote:

> On 02/06/2015 14:28, Stefan Ram wrote:
>>    Sometimes, it has been questioned whether it was wise to
>>    implement
>>
>> typeof null
>> "object"
> 
> It happens due to a bug in the first version of JS [1].
> 
> [1] <http://www.2ality.com/2013/10/typeof-null.html>

Again, your research is flawed.  You are still lacking the healthy 
scepticism that is the mark of a good scientist.  What you are citing is 
*unsubstantiated*, *non-authoritative* *speculation*; likely a historian’s 
fallacy. [1]

It could be a bug, but it could also have been *intentional*.  Only Brendan 
Eich, sole author of the first JavaScript version [2], can say for sure.  

However, that the ECMAScript Language Specification [3], the standard which 
is originally based on JavaScript 1.1 and JScript 1.0 (ibid.), says:

,-[1st edition]
| 
| 4.3.11 Null
| 
| Null is a primitive value that represents the null, empty, or nonexistent 
| reference
  ^^^^^^^^^

,-[2nd Edition]
| 
| 4.3.11 Null value
| 
| The null value is a primitive value that represents the null, empty, or 
| non-existent reference.
               ^^^^^^^^^

,-[Edition 3]
| 
| 4.3.11 Null Value
| 
| The null value is a primitive value that represents the null, empty, or 
| non-existent reference.
               ^^^^^^^^^

,-[5th Edition]
| 
| 4.3.11
| 
| null value
| primitive value that represents the intentional absence of any
| object value.
  ^^^^^^ 

,-[5.1 Edition]
| 
| 4.3.11 null value
| 
|   primitive value that represents the intentional absence
                                        ^^^^^^^^^^^^^^^^^^^
|   of any object value
           ^^^^^

,-[6th Edition Final draft [4]]
| 
| 4.3.12
| 
| null value
| primitive value that represents the intentional absence of any
| object value
  ^^^^^^

indicates that it is _not_ a bug.  “null” *has* something to do with objects 
that other primitive values have not.

Whether it was a good idea to design the “typeof” operator that way, and 
make it hard to tell “null” from a valid object reference is a *separate* 
issue.  As Brendan Eich freely admits in hindsight, he made several *design* 
errors in the creation of JavaScript, not least because the new language had 
to be available soon.  The JavaScript type system was one of them. [5]  
(Employers, take this as a lesson: Rushing software developers for quick 
profit, not allowing to let them think things through and to discuss them 
with their peers, almost invariably leads to bad design decisions that bite 
you even decades later.  BTST.)

____________
[1] <http://en.wikipedia.org/wiki/Historian%27s_fallacy>
[2] Krill, Paul (2008). “JavaScript creator ponders past, future”.
    In: “InfoWorld. Developer World.”
    <http://www.infoworld.com/d/developer-world/javascript-creator-ponders-past-future-704>
[3] <http://www.ecma-international.org/publications/standards/Ecma-262.htm> 
    p.
[4] 
<http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_drafts&cache=cache&media=harmony:ecma-262_6th_edition_final_draft_-04-14-15.pdf>
[5] <https://brendaneich.com/2005/11/js2-design-notes/>

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#28016

On 06/06/15 03:39, Thomas 'PointedEars' Lahn wrote:
> Joao Rodrigues wrote:
>
>> On 02/06/2015 14:28, Stefan Ram wrote:
>>>     Sometimes, it has been questioned whether it was wise to
>>>     implement
>>>
>>> typeof null
>>> "object"
>>
>> It happens due to a bug in the first version of JS [1].
>>
>> [1] <http://www.2ality.com/2013/10/typeof-null.html>
>
> Again, your research is flawed.  You are still lacking the healthy
> scepticism that is the mark of a good scientist.  What you are citing is
> *unsubstantiated*, *non-authoritative* *speculation*; likely a historian’s
> fallacy. [1]

Nonsense.

>
> It could be a bug, but it could also have been *intentional*.  Only Brendan
> Eich, sole author of the first JavaScript version [2], can say for sure.

Yes, Brendan once considered the need to fix typeof [1], but rejected 
that proposal stating: "I think it is too late to fix typeof. The change 
proposed for typeof null will break existing code."

[1] <http://wiki.ecmascript.org/doku.php?id=proposals:typeof>

In another discussion [2], he wrote: "In general, typeof seems like a 
mess that will be hard to reform sensibly."

[2] <http://wiki.ecmascript.org/doku.php?id=discussion:typeof>

>
> However, that the ECMAScript Language Specification [3], the standard which
> is originally based on JavaScript 1.1 and JScript 1.0 (ibid.), says:
>
> ,-[1st edition]
> |
> | 4.3.11 Null
> |
> | Null is a primitive value that represents the null, empty, or nonexistent
> | reference
>    ^^^^^^^^^
>
> ,-[2nd Edition]
> |
> | 4.3.11 Null value
> |
> | The null value is a primitive value that represents the null, empty, or
> | non-existent reference.
>                 ^^^^^^^^^
>
> ,-[Edition 3]
> |
> | 4.3.11 Null Value
> |
> | The null value is a primitive value that represents the null, empty, or
> | non-existent reference.
>                 ^^^^^^^^^
>
> ,-[5th Edition]
> |
> | 4.3.11
> |
> | null value
> | primitive value that represents the intentional absence of any
> | object value.
>    ^^^^^^
>
> ,-[5.1 Edition]
> |
> | 4.3.11 null value
> |
> |   primitive value that represents the intentional absence
>                                          ^^^^^^^^^^^^^^^^^^^
> |   of any object value
>             ^^^^^
>
> ,-[6th Edition Final draft [4]]
> |
> | 4.3.12
> |
> | null value
> | primitive value that represents the intentional absence of any
> | object value
>    ^^^^^^
>
> indicates that it is _not_ a bug.  “null” *has* something to do with objects
> that other primitive values have not.

These references only prove that JS was prematurely standardized, making 
necessary corrections more difficult to be implemented.


-- 
Joao Rodrigues

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

#28017

Joao Rodrigues wrote:

> On 06/06/15 03:39, Thomas 'PointedEars' Lahn wrote:
>> Joao Rodrigues wrote:
>>> [typeof null === "object] happens due to a bug in the first version of 
>>> JS [1].
>>>
>>> [1] <http://www.2ality.com/2013/10/typeof-null.html>
>> […] 
>> It could be a bug, but it could also have been *intentional*.  Only
>> Brendan Eich, sole author of the first JavaScript version [2], can say
>> for sure.
> 
> Yes, Brendan once considered the need to fix typeof [1], but rejected
> that proposal stating: "I think it is too late to fix typeof. The change
> proposed for typeof null will break existing code."
> 
> [1] <http://wiki.ecmascript.org/doku.php?id=proposals:typeof>
> 
> In another discussion [2], he wrote: "In general, typeof seems like a
> mess that will be hard to reform sensibly."
> 
> [2] <http://wiki.ecmascript.org/doku.php?id=discussion:typeof>

AISB, in hindsight Eich admitted *design* errors.  That does not prove 
that it was a *bug caused by the code itself* as claimed by Dr. Rauschmeyer, 
and you, based only on his speculation.  He committed a historian’s fallacy, 
and you an /ipse dixit/ one.

>> However, that the ECMAScript Language Specification [3] […] says:
>> […]
>> indicates that it is _not_ a bug.  “null” *has* something to do with
>> objects that other primitive values have not.
> 
> These references only prove that JS was prematurely standardized, making
> necessary corrections more difficult to be implemented.

Assumption, not evidence.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#28040

On 07/06/15 04:59, Thomas 'PointedEars' Lahn wrote:
> Joao Rodrigues wrote:
>
>> On 06/06/15 03:39, Thomas 'PointedEars' Lahn wrote:
>>> Joao Rodrigues wrote:
>>>> [typeof null === "object] happens due to a bug in the first version of
>>>> JS [1].
>>>>
>>>> [1] <http://www.2ality.com/2013/10/typeof-null.html>
>>> […]
>>> It could be a bug, but it could also have been *intentional*.  Only
>>> Brendan Eich, sole author of the first JavaScript version [2], can say
>>> for sure.
>>
>> Yes, Brendan once considered the need to fix typeof [1], but rejected
>> that proposal stating: "I think it is too late to fix typeof. The change
>> proposed for typeof null will break existing code."
>>
>> [1] <http://wiki.ecmascript.org/doku.php?id=proposals:typeof>
>>
>> In another discussion [2], he wrote: "In general, typeof seems like a
>> mess that will be hard to reform sensibly."
>>
>> [2] <http://wiki.ecmascript.org/doku.php?id=discussion:typeof>
>
> AISB, in hindsight Eich admitted *design* errors.  That does not prove
> that it was a *bug caused by the code itself* as claimed by Dr. Rauschmeyer,
> and you, based only on his speculation.  He committed a historian’s fallacy,
> and you an /ipse dixit/ one.

typeof null == "object" was considered a bug by Brendan Eich - the 
father of JavaScript:

"We have reason to believe typeof null === “object” *is a bug* that 
could bite real content, from our spidering of the web. We have no such 
evidence in favor of breaking typeof String === “function”, and plenty 
of reason to fear incompatibility. It might be best to leave typeof 
utterly alone and deprecate it, *but I’m still in favor of the null 
bug-fix*.

— Brendan Eich 2006/03/31 16:34"

<http://wiki.ecmascript.org/doku.php?id=discussion:typeof>

>
>>> However, that the ECMAScript Language Specification [3] […] says:
>>> […]
>>> indicates that it is _not_ a bug.  “null” *has* something to do with
>>> objects that other primitive values have not.
>>
>> These references only prove that JS was prematurely standardized, making
>> necessary corrections more difficult to be implemented.
>
> Assumption, not evidence.


Evidence proven at:
<http://wiki.ecmascript.org/doku.php?id=discussion:typeof>

-- 
Joao Rodrigues

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

#28075

Joao Rodrigues wrote:

> typeof null == "object" was considered a bug by Brendan Eich - the
> father of JavaScript:
> 
> "We have reason to believe typeof null === “object” *is a bug* that
> could bite real content, from our spidering of the web. We have no such
> evidence in favor of breaking typeof String === “function”, and plenty
> of reason to fear incompatibility. It might be best to leave typeof
> utterly alone and deprecate it, *but I’m still in favor of the null
> bug-fix*.
> 
> — Brendan Eich 2006/03/31 16:34"
> 
> <http://wiki.ecmascript.org/doku.php?id=discussion:typeof>

Much better.  Still _not_ an admission that it is an implementation bug 
caused by the original JavaScript code as Dr. Rauschmeyer and you claimed, 
and not a clear admission that it is a bug at all (“reason to believe”,
not “is”).  But at least properly quoted and cited, and substantiated.

>>>> However, that the ECMAScript Language Specification [3] […] says:
>>>> […]
>>>> indicates that it is _not_ a bug.  “null” *has* something to do with
>>>> objects that other primitive values have not.
>>> These references only prove that JS was prematurely standardized, making
>>> necessary corrections more difficult to be implemented.
>> Assumption, not evidence.
> 
> Evidence proven at: […]

Evidence is not proven, but presented.  “Evidence” is synonymous with 
“proof; so “to prove evidence” contains redundancy, at best.

You should improve your understanding of English; that way the number of 
your misconceptions – about what people said and wrote, and what they meant 
when they said and wrote it – might decrease.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#28082

Thomas Lahn wrote:
> Joao Rodrigues wrote:
> 
>> typeof null == "object" was considered a bug by Brendan Eich - the
>> father of JavaScript:
>>
>> "We have reason to believe typeof null === “object” *is a bug* that
>> could bite real content, from our spidering of the web. We have no such
>> evidence in favor of breaking typeof String === “function”, and plenty
>> of reason to fear incompatibility. It might be best to leave typeof
>> utterly alone and deprecate it, *but I’m still in favor of the null
>> bug-fix*.
>>
>> — Brendan Eich 2006/03/31 16:34"
>>
>> <http://wiki.ecmascript.org/doku.php?id=discussion:typeof>
> 
> Much better.  Still _not_ an admission that it is an implementation bug 
> caused by the original JavaScript code as Dr. Rauschmeyer and you claimed, 
> and not a clear admission that it is a bug at all (“reason to believe”,
> not “is”).  But at least properly quoted and cited, and substantiated.

It is still _not_ an admission that *you are wrong* and acting like a
fool trying to deceive everyone that typeof null === 'object' is not a
bug. Remember Brendan Eich, Douglas Crockford and others have said it is
more than once. Now shall we believe in Thomas Lahn or Brendan Eich?

If you had read carefully what Dr Rauschmeyer wrote [1], you'd realize
the bug in the C++ code that he posted. Besides, there is another
article that shows the same problem in the C++ code of Google's V8
implementation [2].

[1] <http://www.2ality.com/2013/10/typeof-null.html>
[2] <http://kiro.me/blog/typeof_null.html>

"No man is more blind than the one who refuses to see".


-- 
Joao Rodrigues

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

#28084

Joao Rodrigues wrote:

> Thomas Lahn wrote:
>
>> Much better.  Still _not_ an admission that it is an implementation bug 
>> caused by the original JavaScript code as Dr. Rauschmeyer and you claimed, 
>> and not a clear admission that it is a bug at all (“reason to believe”,
>> not “is”).  But at least properly quoted and cited, and substantiated.
> 
> It is still _not_ an admission that *you are wrong* and acting like a
> fool trying to deceive everyone that typeof null === 'object' is not a
> bug. Remember Brendan Eich, Douglas Crockford and others have said it is
> more than once. Now shall we believe in Thomas Lahn or Brendan Eich?

Argument from authority.

> If you had read carefully what Dr Rauschmeyer wrote [1], you'd realize
> the bug in the C++ code that he posted. Besides, there is another
> article that shows the same problem in the C++ code of Google's V8
> implementation [2].

I haven't read the second article, but Dr. Rauschmeyer claims there is a
bug without actual evidence.  The respective code could have been
written this way deliberately.  Consider that typeof null was *supposed*
to be `object` – why should have an additional check for JSVAL_NULL be
added?  A comment would have clarified the issue, but there is none, so
we only can guess.

> [1] <http://www.2ality.com/2013/10/typeof-null.html>
> [2] <http://kiro.me/blog/typeof_null.html>

-- 
Christoph M. Becker

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

#28085

On 11/06/2015 10:28, Christoph M. Becker wrote:
> Joao Rodrigues wrote:
> 
>> Thomas Lahn wrote:
>>
>>> Much better.  Still _not_ an admission that it is an implementation bug 
>>> caused by the original JavaScript code as Dr. Rauschmeyer and you claimed, 
>>> and not a clear admission that it is a bug at all (“reason to believe”,
>>> not “is”).  But at least properly quoted and cited, and substantiated.
>>
>> It is still _not_ an admission that *you are wrong* and acting like a
>> fool trying to deceive everyone that typeof null === 'object' is not a
>> bug. Remember Brendan Eich, Douglas Crockford and others have said it is
>> more than once. Now shall we believe in Thomas Lahn or Brendan Eich?
> 
> Argument from authority.

No, it is not a fallacy because 'Argument from authority' happens when
appealing to the position of an authority or authorities to dismiss
evidence, and that is not the case.

Brendan Eich *created* JavaScript in May, 1995 while working at
Netscape, and he has been an active TC39 member in Ecma since 1996. As
such, he is the very authority here. Besides, it is a *fact*, not an
evidence, that Brendan Eich *recognized* publicly the typeof_null_bug [1].

[1] <http://wiki.ecmascript.org/doku.php?id=discussion:typeof>

Now Thomas Lahn has been blathering that there is no bug at all in
typeof null without evidence or references. Maybe Thomas has used his
Vulcan powers to psionically connect with Brandan's mind and has
discovered the whole thing and, therefore, Thomas is correct.

> 
>> If you had read carefully what Dr Rauschmeyer wrote [1], you'd realize
>> the bug in the C++ code that he posted. Besides, there is another
>> article that shows the same problem in the C++ code of Google's V8
>> implementation [2].
> 
> I haven't read the second article, but Dr. Rauschmeyer claims there is a
> bug without actual evidence.  The respective code could have been
> written this way deliberately.

The second article [2] shows that Google's V8 engine implementation had
to conform to the nonsense of typeof null === 'object', despite the fact
that null is a primitive value. In this case, there was not a bug in V8
code as it was done on purpose to comply with the ECMAScript Language
Specification, which BTW needed a fix according to Brendan's words [1].

[2] <http://kiro.me/blog/typeof_null.html>

-- 
Joao Rodrigues

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

#28086

Joao Rodrigues wrote:

> On 11/06/2015 10:28, Christoph M. Becker wrote:
>
> Brendan Eich *created* JavaScript in May, 1995 while working at
> Netscape, and he has been an active TC39 member in Ecma since 1996. As
> such, he is the very authority here. Besides, it is a *fact*, not an
> evidence, that Brendan Eich *recognized* publicly the typeof_null_bug [1].
> 
> [1] <http://wiki.ecmascript.org/doku.php?id=discussion:typeof>

Brendan Eich wrote:

| We have reason to believe typeof null === “object” is a bug that
| could bite real content, from our spidering of the web.

So yes, he admits that typeof null === "object" is a bug.  However, a
few lines above it is written:

| From bug fixes where the typeof fixing started, more about the typeof
| null === “null” fix:

Ah, obviously his comment refers to that.  Interestingly, the term "bug
fixes" is linked to "Bug fixes to ECMA-262".  ECMA-262 is a
specification, not an implementation, so obviously, Brendan Eich
admitted a *specification* bug.

Contrary to that, Dr. Rauschmeyer claims that typeof null === "object"
would have been an *implementation* bug in the first version of JavaScript.

-- 
Christoph M. Becker

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

#28087

Christoph M. Becker wrote:
> Joao Rodrigues wrote:
> 
>> On 11/06/2015 10:28, Christoph M. Becker wrote:
>>
>> Brendan Eich *created* JavaScript in May, 1995 while working at
>> Netscape, and he has been an active TC39 member in Ecma since 1996. As
>> such, he is the very authority here. Besides, it is a *fact*, not an
>> evidence, that Brendan Eich *recognized* publicly the typeof_null_bug [1].
>>
>> [1] <http://wiki.ecmascript.org/doku.php?id=discussion:typeof>
> 
> Brendan Eich wrote:
> 
> | We have reason to believe typeof null === “object” is a bug that
> | could bite real content, from our spidering of the web.
> 
> So yes, he admits that typeof null === "object" is a bug.  However, a
> few lines above it is written:
> 
> | From bug fixes where the typeof fixing started, more about the typeof
> | null === “null” fix:
> 
> Ah, obviously his comment refers to that.  Interestingly, the term "bug
> fixes" is linked to "Bug fixes to ECMA-262".  ECMA-262 is a
> specification, not an implementation, so obviously, Brendan Eich
> admitted a *specification* bug.
> 
> Contrary to that, Dr. Rauschmeyer claims that typeof null === "object"
> would have been an *implementation* bug in the first version of JavaScript.
> 

IMO, Dr. Rauschmeyer is right when using "implementation" instead of
"specification" bug because he analyses a code excerpt from the first
version of JavaScript which was released by the end of 1995, while
Netscape took JS to Ecma in November 1996 (one year later), and the
first edition of ECMAScript was released on June 1997.


-- 
Joao Rodrigues

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

#28088

Joao Rodrigues wrote:

> Christoph M. Becker wrote:
>> Joao Rodrigues wrote:
>>
>>> [1] <http://wiki.ecmascript.org/doku.php?id=discussion:typeof>
>>
>> Brendan Eich wrote:
>>
>> | We have reason to believe typeof null === “object” is a bug that
>> | could bite real content, from our spidering of the web.
>>
>> So yes, he admits that typeof null === "object" is a bug.  However, a
>> few lines above it is written:
>>
>> | From bug fixes where the typeof fixing started, more about the typeof
>> | null === “null” fix:
>>
>> Ah, obviously his comment refers to that.  Interestingly, the term "bug
>> fixes" is linked to "Bug fixes to ECMA-262".  ECMA-262 is a
>> specification, not an implementation, so obviously, Brendan Eich
>> admitted a *specification* bug.
>>
>> Contrary to that, Dr. Rauschmeyer claims that typeof null === "object"
>> would have been an *implementation* bug in the first version of JavaScript.
> 
> IMO, Dr. Rauschmeyer is right when using "implementation" instead of
> "specification" bug because he analyses a code excerpt from the first
> version of JavaScript which was released by the end of 1995, while
> Netscape took JS to Ecma in November 1996 (one year later), and the
> first edition of ECMAScript was released on June 1997.

Well, let's agree to disagree. :)

Actually, I don't mind whether Dr. Rauschmeyer is right in this case,
and whether this is a bug at all.  Most importantly, it (typeof null ===
"object") is a behavior one has to be aware of.

-- 
Christoph M. Becker

[toc] | [prev] | [standalone]

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

csiph-web