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

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

Re: "i = i|0"

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: "i = i|0" Ike Naar <ike@iceland.freeshell.org> - 2014-06-11 21:09 +0000
    Re: "i = i|0" James Kuyper <jameskuyper@verizon.net> - 2014-06-11 17:37 -0400
      Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-12 00:56 +0200
        Re: "i = i|0" raltbos@xs4all.nl (Richard Bos) - 2014-06-12 11:41 +0000
          Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-12 14:28 +0200
        Re: "i = i|0" James Kuyper <jameskuyper@verizon.net> - 2014-06-12 08:19 -0400
          Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-12 14:45 +0200
            Re: "i = i|0" James Kuyper <jameskuyper@verizon.net> - 2014-06-12 09:25 -0400
              Re: "i = i|0" raltbos@xs4all.nl (Richard Bos) - 2014-06-12 14:50 +0000
                Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-12 16:55 +0200
                  Re: "i = i|0" Keith Thompson <kst-u@mib.org> - 2014-06-12 11:28 -0700
                    Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-12 20:46 +0200
                    Re: "i = i|0" Christoph Michael Becker <cmbecker69@arcor.de> - 2014-06-12 20:58 +0200
                      Re: "i = i|0" Kaz Kylheku <kaz@kylheku.com> - 2014-06-12 19:20 +0000
                        Re: "i = i|0" Christoph Michael Becker <cmbecker69@arcor.de> - 2014-06-12 22:13 +0200
                          Re: "i = i|0" Kaz Kylheku <kaz@kylheku.com> - 2014-06-12 21:15 +0000
                            Re: "i = i|0" Christoph Michael Becker <cmbecker69@arcor.de> - 2014-06-12 23:59 +0200
                              Re: "i = i|0" Christoph Michael Becker <cmbecker69@arcor.de> - 2014-06-13 01:10 +0200
                              Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-13 01:52 +0200
                              ECMAScript standards (was: "i = i|0") Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-15 12:53 +0200
                            Re: "i = i|0" Stephen Sprunk <stephen@sprunk.org> - 2014-06-12 17:11 -0500
                              Re: "i = i|0" Denis McMahon <denismfmcmahon@gmail.com> - 2014-06-12 22:40 +0000
                              Re: "i = i|0" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-06-12 22:44 +0000
                              Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-13 01:16 +0200
                                Re: "i = i|0" raltbos@xs4all.nl (Richard Bos) - 2014-06-16 12:55 +0000
                                  Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-16 22:44 +0200
                              Re: "i = i|0" Thomas Richter <thor@math.tu-berlin.de> - 2014-06-13 19:16 +0200
                                Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-13 19:21 +0200
                                Re: "i = i|0" Tim Streater <timstreater@greenbee.net> - 2014-06-13 18:24 +0100
                                  Re: "i = i|0" Kaz Kylheku <kaz@kylheku.com> - 2014-06-13 21:25 +0000
              Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-12 17:13 +0200
                Re: "i = i|0" raltbos@xs4all.nl (Richard Bos) - 2014-06-12 15:20 +0000
                  Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-12 17:32 +0200
                    Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-17 12:30 +0200
                Re: "i = i|0" James Kuyper <jameskuyper@verizon.net> - 2014-06-12 12:17 -0400
                  Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-12 20:01 +0200
                    Re: "i = i|0" James Kuyper <jameskuyper@verizon.net> - 2014-06-12 16:13 -0400
                    Re: "i = i|0" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-06-12 20:44 +0000
                    Re: "i = i|0" Kaz Kylheku <kaz@kylheku.com> - 2014-06-12 20:59 +0000
                      Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-13 01:22 +0200
                        Re: "i = i|0" Martin Shobe <martin.shobe@yahoo.com> - 2014-06-12 19:48 -0500
                          Re: "i = i|0" "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-06-12 18:32 -0700
                            Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-13 12:12 +0200
                  Re: "i = i|0" John Harris <niam@jghnorth.org.uk.invalid> - 2014-06-13 10:16 +0100
                    Re: "i = i|0" Tim Streater <timstreater@greenbee.net> - 2014-06-13 11:44 +0100
            Re: "i = i|0" "BartC" <bc@freeuk.com> - 2014-06-12 15:06 +0100
              Re: "i = i|0" Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-06-12 16:54 +0200

Page 3 of 3 — ← Prev page 1 2 [3]

#24802

On 6/12/2014 6:22 PM, Thomas 'PointedEars' Lahn wrote:
> Kaz Kylheku wrote:
>
>> On 2014-06-12, Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
>>>> I did indeed search the Web. The Wikipedia page for JavaScript says
>>>> "JavaScript (JS) is a dynamic computer programming language". so you'll
>>>> have to forgive me for thinking that there might be some truth in that
>>>> statement.
>>>
>>> First one has to define what “dynamic programming language” means.
>>
>> Very easy. A dynamic programming language is characterized by late binding
>> features. For instance, type is principally a run-time property of
>> values/objects, rather than of pieces of program source code. Functions
>> and types may defined and redefined while the program is running.  These
>> capabilities would be a bare minimum.  Dynamic languages also usually
>> exhibit introspection: various entities that describe the program, and
>> which disappear after compile time in static languages tend to be
>> available in a useful run-time representation in dynamic languages. For
>> instance "class" or "variable name" might be strictly compile-time
>> concepts in a static language, but in a dynamic language they might be
>> run-time values of some sort.
>
> That is an interesting definition that you have just made up.  And it does
> not fully apply to JavaScript (or other ECMAScript implementations) either.
>

No it's not a definition that he just made up. See

http://en.wikipedia.org/wiki/Dynamic_programming_language
http://stackoverflow.com/questions/4913105/what-qualifies-a-programming-language-as-dynamic
http://wiki.tcl.tk/13325

Martin Shobe

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

#24803

On Thursday, June 12, 2014 7:48:16 PM UTC-5, Martin Shobe wrote:
> On 6/12/2014 6:22 PM, Thomas 'PointedEars' Lahn wrote:
> > Kaz Kylheku wrote:
> >
> >> On 2014-06-12, Thomas 'PointedEars' Lahn wrote:
> >>>> I did indeed search the Web. The Wikipedia page for JavaScript says
> >>>> "JavaScript (JS) is a dynamic computer programming language". so you'll
> >>>> have to forgive me for thinking that there might be some truth in that
> >>>> statement.
> >>>
> >>> First one has to define what "dynamic programming language" means.
> 
> >>
> >> Very easy. A dynamic programming language is characterized by late binding
> >> features. For instance, type is principally a run-time property of
> >> values/objects, rather than of pieces of program source code. Functions
> >> and types may defined and redefined while the program is running.  These
> >> capabilities would be a bare minimum.  Dynamic languages also usually
> >> exhibit introspection: various entities that describe the program, and
> >> which disappear after compile time in static languages tend to be
> >> available in a useful run-time representation in dynamic languages. For
> >> instance "class" or "variable name" might be strictly compile-time
> >> concepts in a static language, but in a dynamic language they might be
> >> run-time values of some sort.
> >
> > That is an interesting definition that you have just made up.  And it does
> > not fully apply to JavaScript (or other ECMAScript implementations) either.
> >
> 
> No it's not a definition that he just made up. See
> 
> http://en.wikipedia.org/wiki/Dynamic_programming_language
> 
> http://stackoverflow.com/questions/4913105/what-qualifies-a-programming-language-as-dynamic
> 
> http://wiki.tcl.tk/13325

The very fact that Wikipedia and Stack Overflow are being used as instruments of truth in this matter is slightly disturbing.

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

#24815

Stefan Ram wrote:

> "Michael Haufe (TNO)" <tno@thenewobjective.com> writes:
>> The very fact that Wikipedia and Stack Overflow are being
>> used as instruments of truth in this matter is slightly
>> disturbing.
> 
>   In this newsgroup, I deem relevant the MDN, which says:

(Again you have neglected to give proper reference.  *Where* *exactly* on 
MDN have you read what you quoted?  You are, at least by appearance, at 
least an aspiring scientist; you should know better than this [especially as 
I told you several times before].)

MDN (Mozilla Developer Network) certainly is relevant; but it is a wiki as 
well.  It was _not_ solely written by the people developing *Mozilla* 
JavaScript [0] (which is what [MDN] describes), so it cannot be 
authoritative in any way.  The validity of the statements in it depend on 
the knowledge and experience of the people editing it, the time they can 
invest in doing that, and the diligence they can show.  (Me included.)

So, unsurprisingly, some invented terminology, and misleading, even 
fundamentally wrong statements can still be found there.  What you quoted is 
a good example of that:

>       »JavaScript's dynamic capabilities include runtime
>       object construction, 

True; you can create new objects at runtime that can have properties that 
have not previously been defined:

  var foo = {
    bar: 42
  };

  // …

  foo[some_variable_value] = some_other_variable_value;

> variable parameter lists,

No, in the ECMAScript terminology ([ES] §13), JavaScript parameter lists are 
_not_ variable: it is not possible to change the name or number of formal 
parameters of a function at runtime without creating a new function (and 
even that is error-prone, see below).

However, the length of *argument* lists of function *calls* ([ES] §§11.2.3 
and 11.2.4) is: in general, you can pass more or less arguments to in a 
function call than the function has formal parameters, and you can access 
those arguments using the “arguments” object in function context.  In this 
sense, the term “function” applies also to methods, properties of objects 
whose value is a reference to a callable object.  But the method may throw 
an exception or return an error value if an unsupported number of arguments 
was passed.  Some methods of built-in objects throw exceptions in that case 
[ES], many methods of host objects do (e.g., those specified in [DOM]).

>       function variables,

What is a “function variable”?  Neither the original JavaScript 
documentation ([DevEdge]) nor [ES] define this term.  It appears to be an 
ad-hoc invention at MDN.

It is correct to say that functions are first-class objects in ECMAScript 
implementations, including Mozilla JavaScript, in the sense that they can be 
both l-values and r-values.  In that sense, in

  var f = function () {};

where (a reference to) a function is an r-value, “f” could be defined as 
being a “function variable”; but that is a very limited view of this 
language feature.  For example, you can pass a reference to a function to 
another function or even the same function:

  function f (f2)
  {
    /* something */
  }

  f(f);

Here, “f” is _not_ a variable, it is a function name which becomes the name 
of a property of the global object; “f2” also is _not_ a variable, it is 
(the name of) a formal parameter of the function named “f”.

And, does “f” cease to be a “function variable” when, as there is only 
dynamic type-checking in these implementations, it is assigned a non-
function value?

  f = 23;

The misconception might have occurred in the author(s) because up to 
including ECMAScript Edition 3 the creation of Function instances from 
/FunctionDeclaration/s was described as part of a process labeled “Variable 
Instantiation” (because it involves evaluating /VariableDeclaration/s as 
well; [ES3], §10.1.3)

>       dynamic script creation (via eval),

This statement is at least debatable.  eval() does not help creating a 
script dynamically.  A value of the String type it is passed as argument is 
interpreted as an ECMAScript /Program/ ([ES], §15.1.2.1), taking into 
account the (Mozilla) JavaScript extensions of the ECMAScript grammar [MDN].

>       object introspection (via for ... in),

True, but insufficient; probably simplifying or historic, potentially 
misleading.  A for-in statement can only show the *enumerable* properties 
that an object has and inherits. ([ES], §12.6.4)

Methods introduced with ECMAScript Edition 5, namely 
Object.getOwnPropertyNames() ([ES], §15.2.3.4) – which considers non-
enumerable properties, but ignores inherited ones –, 
Object.getOwnPropertyDescriptor() ([ES], §15.2.3.3) – which gives 
information about property attributes –, and __proto__ and its ES3+ 
counterpart Object.getPrototypeOf() ([ES], §15.2.3.2) – which allows to 
inspect the inherited ones –, allow for much deeper introspection.  (Current 
JavaScript versions are implementations of ECMAScript Ed. 5 and the Ed. 6 
Draft. [MDN])

>       and source code recovery (JavaScript programs can decompile function
>       bodies back into their source text)«

Wishful thinking, potentially misleading.  That there is the *possibility* 
of this is a consequence of the fact that Function instances (objects 
created with a /FunctionDeclaration/, /FunctionExpression/ or the Function 
constructor) inherit a “toString” method from their prototype, the object 
initially referred to by τhe expression “Function.prototype”.  That 
toString() method is specified in [ES] to return a string value that matches 
the /FunctionDeclaration/ production.

However, no guarantee is given anywhere in the original JavaScript 
documentation (eventually at [DevEdge]) or in the ECMAScript Language 
Specification that it will be the decompiled source code.  In fact, the 
Specification explicitly says that the value is implementation-dependent 
([ES], §15.3.4.2).  That implementation-dependence can be observed when 
comparing the return values of various “JavaScript”s (ES implementations 
that have “JavaScript” in their name), showing that they are indeed 
different implementations of that Specification.  For example, some 
“JavaScript”s return a string value containing the original comments while 
others do not.  We have discussed this here before.

Finally, the term “function” appears to be underdefined in that statement.  
The above does not apply to all functions in the sense of callable objects, 
but only to *user-defined* functions as defined in the first paragraph of 
this section.  As an example, the built-in object referred to by the initial 
value of “Object.prototype.toString” is a Function instance but it 
violates/extends the Specification as its toString() method returns

  "function toString() {\n    [native code]\n}"

which (evaluated) cannot be produced by /FunctionDeclaration/: “[native 
code]” is not a valid expression.

>   A definitions of the meaning of a term is not »true« or
>   »false«, rather it is »agreed upon« or »not agreed upon«
>   within a certain group of parties.

For reasons that should be obvious by now, I cannot agree with the cited 
statement as a whole; in fact, I find that I can fully agree (in the sense 
that I would sign it) only with the first phrase of its first sentence.

__________
[0]       <https://developer.mozilla.org/en-US/>, “Help improve MDN”
[DevEdge] 
<http://wayback.archive.org/web/20040929085837/http://devedge.netscape.com/central/javascript/>
[DOMCore] <http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html>
[ES]      <http://ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf>
[ES3]     <http://ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%203rd%20edition,%20December%201999.pdf>
[MDN]     <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference>
-- 
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]

#24814

On Thu, 12 Jun 2014 12:17:46 -0400, James Kuyper
<jameskuyper@verizon.net> wrote:

>On 06/12/2014 11:13 AM, Thomas 'PointedEars' Lahn wrote:


  <snip> 
>> There is no programming language called ”javascript”, and from that 
>> everything else follows.  STFW.
>
>I did indeed search the Web.
  <snip>

I'm afraid James has dropped into an argument that has been going on
for several years. The question is how to refer to a variety of
implementations, some of them trade-marked, in a variety of
environments : browsers, web servers, etc.

Some of us want a one-word generic name and think that lower case
'javascript' is as good as any. Thomas rejects that idea absolutely,
often with accompanying abuse.

  John

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

#24816

In article <laglp9h6q4nv9pqn1ug23i9h9elt38bc7j@4ax.com>, John Harris
<niam@jghnorth.org.uk.invalid> wrote:

> On Thu, 12 Jun 2014 12:17:46 -0400, James Kuyper
> <jameskuyper@verizon.net> wrote:
> 
> >On 06/12/2014 11:13 AM, Thomas 'PointedEars' Lahn wrote:
> 
>   <snip> 
> >> There is no programming language called ‰javascript‰, and from that 
> >> everything else follows.  STFW.
> >
> >I did indeed search the Web.
>   <snip>
> 
> I'm afraid James has dropped into an argument that has been going on
> for several years. The question is how to refer to a variety of
> implementations, some of them trade-marked, in a variety of
> environments : browsers, web servers, etc.
> 
> Some of us want a one-word generic name and think that lower case
> 'javascript' is as good as any. Thomas rejects that idea absolutely,
> often with accompanying abuse.

It *is* as good as any. And the accompanying abuse is, IMO, "usually"
rather than merely "often". Suggested responses to PointyHead vary from
neutral to returning the abuse with interest. One can, of course,
ignore him, but that might confuse newcomers.

Hmmm, perhaps a FAQ entry about his egregious behaviour might be in
order, so newcomers can be quickly warned.

-- 
"Once you adopt the unix paradigm, the variants cease to be a problem - you
bitch, of course, but that's because bitching is fun, unlike M$ OS's, where 
bitching is required to keep your head from exploding." - S Stremler in afc

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

#24772

"Thomas 'PointedEars' Lahn" <PointedEars@web.de> wrote in message
news:2122350.lP4zVSTnZj@PointedEars.de...
> [F'up2 comp.lang.javascript]
>
> James Kuyper wrote in comp.lang.c:

>> but for this particular C expert, the very existence of
>> comp.lang.javascript seems to contradict the most obvious meaning for
>> that

> so), and the newsgroup name is case-insensitive as newsgroup names usually
> go.  (You would not talk about “c” either, would you?)

"c" by itself is ambiguous. "javascript" considerably less so; even without
context, people will know what you were on about (ie. the language formerly
known as Javascript).

>> That doesn't change my main point: the conversion is still required - it
>> can't be optimized away. Or am I wrong about that, too?
>
> The only possible optimization of
>
>  function f(i) {
>    i = i|0;
>    return (i + 1)|0;
>  }
>
> in terms of runtime is
>
>  function f(i) {
>    return ((i|0) + 1)|0;
>  }

If that function is being called as a=f(b), then another optimisation might
be:

 a = b+1;

if the function source is visible at the call-site (especially if being
converted from c source code).

But, how important is that |0 anyway; what would happen if the function was
just:

function f(i) }
  return i+1;
} ?

(I assume that in this language, it is possible to write such a function,
but would anyone actually bother with sticking |0 everywhere? If called with 
an invalid argument, it would still fail wouldn't it?)

-- 
Bartc
 

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

#24774

[F'up2 comp.lang.javascript]

BartC wrote in comp.lang.javascript, comp.lang.c:

> "Thomas 'PointedEars' Lahn" <PointedEars@web.de> wrote in message
> news:2122350.lP4zVSTnZj@PointedEars.de...

It's attribution *line*, _not_ attribution novel.

>> [F'up2 comp.lang.javascript]

Why have you ignored that?  This discussion has nothing to do with C 
(anymore).

>> James Kuyper wrote in comp.lang.c:
>>> but for this particular C expert, the very existence of
>>> comp.lang.javascript seems to contradict the most obvious meaning for
>>> that
>> 
>> so), and the newsgroup name is case-insensitive as newsgroup names
>> usually go.  (You would not talk about “c” either, would you?)
> 
> "c" by itself is ambiguous. "javascript" considerably less so; even
> without context, people will know what you were on about (ie. the language
> formerly known as Javascript).

So those “people” are adopting a new term for a non-existing language that 
is thought to be a successor to some other non-existing language?

(You have no clue what you are talking about.  Visit the ECMAScript Support 
Matrix website to get a minimum one.)
 
>>  function f(i) {
>>    i = i|0;
>>    return (i + 1)|0;
>>  }
>> […]
> 
> If that function is being called as a=f(b), then another optimisation
> might be:
> 
>  a = b+1;
> 
> if the function source is visible at the call-site (especially if being
> converted from c source code).

No, as that would change the semantics considerably.  I also think inlining 
was not what was being asked for here; it is too obvious.
 
> But, how important is that |0 anyway; what would happen if the function
> was just:
> 
> function f(i) }
>   return i+1;
> } ?

Then the value of the “i” parameter would not necessarily be a numeric value 
whose fractional part is zero, neither would be the return value.
 
> (I assume that in this language, it is possible to write such a function,
> but would anyone actually bother with sticking |0 everywhere? If called
> with an invalid argument, it would still fail wouldn't it?)

What is “this language”?

Your questions have been answered before.  Please read more carefully.
 
-- 
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] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

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

csiph-web