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

Groups > comp.lang.c > #45811 > unrolled thread

Re: "i = i|0"

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

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" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-06-11 13:55 -0700
    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" 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: ECMAScript standards (was: "i = i|0") Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-06-15 03:59 -0700
                                    Re: ECMAScript standards (was: "i = i|0") gazelle@shell.xmission.com (Kenny McCormack) - 2014-06-15 14:39 +0000
                                      Re: ECMAScript standards BGB <cr88192@hotmail.com> - 2014-06-15 11:41 -0500
                              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" 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" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-06-13 10:59 -0700
                                  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" 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" 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
            Re: "i = i|0" Denis McMahon <denismfmcmahon@gmail.com> - 2014-06-12 14:11 +0000
              Re: "i = i|0" James Kuyper <jameskuyper@verizon.net> - 2014-06-12 12:20 -0400
        Re: "i = i|0" BGB <cr88192@hotmail.com> - 2014-06-11 22:59 -0500
          Re: "i = i|0" James Kuyper <jameskuyper@verizon.net> - 2014-06-12 08:06 -0400
            Re: "i = i|0" BGB <cr88192@hotmail.com> - 2014-06-12 08:39 -0500

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

#45811 — Re: "i = i|0"

On Wednesday, June 11, 2014 9:20:35 PM UTC+1, Stefan Ram wrote:
> Newsgroups: comp.lang.c,comp.lang.javascript
> 
>   I have read this in a World-Wide Web encyclopedia:
> 
> For example, given the following C code:
>  
> int f(int i) {
>   return i + 1;
> }
> 
> Emscripten would output the following JS code:
> 
> function f(i) {
>   i = i|0;
>   return (i + 1)|0;
> }
> 
>   Do you think that the �|0� is necessary to express the
>   C semantics in JavaScript, or could the speed of the
>   generated code be improved by omitting it?
> 
I don't have much knowledge of the underlying system.
But my guess is that since Javascript uses a weakly typed
system, "i +1" can mean several things depending on the 
type of i. i|0 probably forces it to an integer, and the 
converter just adds that to every integer expression, whether
strictly required or not.

[toc] | [next] | [standalone]

#45814

On 2014-06-11, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>   When they then call the function with non-integer arguments
>   its their fault. (Or they can write a |0 wrapper instead
>   of requiring each and every function to do |0 and thereby
>   possibly slowing down execution and enlarging code size.)

With a decent optimizing compiler, do you think that |0 would
slow down execution or enlarge code size?

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

#45816

On 06/11/2014 05:09 PM, Ike Naar wrote:
> On 2014-06-11, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>>   When they then call the function with non-integer arguments
>>   its their fault. (Or they can write a |0 wrapper instead
>>   of requiring each and every function to do |0 and thereby
>>   possibly slowing down execution and enlarging code size.)
> 
> With a decent optimizing compiler, do you think that |0 would
> slow down execution or enlarge code size?

I'm no JS experts, but so far I haven't seen any responses from those
who are, so I'll throw in my guesses.

It seems reasonable to me that it would - in javascript, |0 doesn't just
cause the integer value to be unchanged (something a smart compiler
could drop) - it also (and first) causes conversion to a 32-bit integer
type, if necessary. The compiler can't be expected to know that such a
conversion will not, in fact, be necessary. This is a substantial
difference from the original C code, where such conversions would occur,
if necessary, in the calling code, where the compiler can be sure. A JS
compiler would have to generate code to check the type of the argument,
and code to perform the conversion. The checking part, at least, will
have to be executed even though the conversion code will not.

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

#45825

[F'up2 comp.lang.javascript]

James Kuyper wrote:

> On 06/11/2014 05:09 PM, Ike Naar wrote:
>> On 2014-06-11, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>>>   When they then call the function with non-integer arguments
>>>   its their fault. (Or they can write a |0 wrapper instead
>>>   of requiring each and every function to do |0 and thereby
>>>   possibly slowing down execution and enlarging code size.)
>> 
>> With a decent optimizing compiler, do you think that |0 would
>> slow down execution or enlarge code size?
> 
> I'm no JS experts,

That much is obvious.

> but so far I haven't seen any responses from those who are,

Usenet is not a real-time communications medium.  Besides, what one sees may 
very well be different from what someone else sees, due to different feeds 
(different speeds and Paths), scorefiles, killfiles, and so on.

> so I'll throw in my guesses.

The reference material is freely available; there is no need to guess.  If 
you are not sure, just refrain from posting.  Nobody is being helped by wild 
guesses from people who have a smattering; you do not have to save the world 
alone.
 
> It seems reasonable to me that it would - in javascript, |0 doesn't just

There is no javascript. [0]

> cause the integer value to be unchanged (something a smart compiler
> could drop) - it also (and first) causes conversion to a 32-bit integer
> type, if necessary.

No, it causes conversion to a 64-bit floating-point value that represents a 
32-bit integer value.

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

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

#45847

On 06/11/2014 06:56 PM, Thomas 'PointedEars' Lahn wrote:
> [F'up2 comp.lang.javascript]
> 
> James Kuyper wrote:
> 
>> On 06/11/2014 05:09 PM, Ike Naar wrote:
>>> On 2014-06-11, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>>>>   When they then call the function with non-integer arguments
>>>>   its their fault. (Or they can write a |0 wrapper instead
>>>>   of requiring each and every function to do |0 and thereby
>>>>   possibly slowing down execution and enlarging code size.)
>>>
>>> With a decent optimizing compiler, do you think that |0 would
>>> slow down execution or enlarge code size?
>>
>> I'm no JS experts,
> 
> That much is obvious.
> 
>> but so far I haven't seen any responses from those who are,
> 
> Usenet is not a real-time communications medium.  Besides, what one sees may 
> very well be different from what someone else sees, due to different feeds 
> (different speeds and Paths), scorefiles, killfiles, and so on.

Yes, know all of that. But I was getting impatient for someone to reply.

>> so I'll throw in my guesses.
> 
> The reference material is freely available; there is no need to guess.

My comments were not pure guesses. I searched for reference materials,
found one (I didn't take notes, so I'm not sure which one) that was
identified as an official standard (though possibly not the relevant
one). It defined the behavior of bit-wise or in terms of calls to
ToInt32() for each operand.

>  If 
> you are not sure, just refrain from posting.  Nobody is being helped by wild 
> guesses from people who have a smattering; you do not have to save the world 
> alone.
>  
>> It seems reasonable to me that it would - in javascript, |0 doesn't just
> 
> There is no javascript. [0]

That comment requires explanation. What you meant by it may be perfectly
obvious to those who monitor comp.lang.javascript, but for this
particular C expert, the very existence of comp.lang.javascript seems to
contradict the most obvious meaning for that comment.

The [0] seems to be intended as a cross-reference, but I couldn't locate it.

>> cause the integer value to be unchanged (something a smart compiler
>> could drop) - it also (and first) causes conversion to a 32-bit integer
>> type, if necessary.
> 
> No, it causes conversion to a 64-bit floating-point value that represents a 
> 32-bit integer value.

If I'd bothered to look up what ToInt32() did, I would have noticed, but
the name seemed perfectly clear, so I didn't bother. It would never have
occurred to me that ToInt32() might have such behavior. From a C
perspective, that's a mind-bogglingly inefficient way of doing things,
though I suppose it makes sense from a javascript perspective (Sorry - I
couldn't figure out how to write that sentence without referring to the
thing you've said is non-existent).

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?
-- 
James Kuyper

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

#45849

[F'up2 comp.lang.javascript]

James Kuyper wrote in comp.lang.c:

> On 06/11/2014 06:56 PM, Thomas 'PointedEars' Lahn wrote:
>> James Kuyper wrote:
>>> It seems reasonable to me that it would - in javascript, |0 doesn't just
>> 
>> There is no javascript. [0]
> 
> That comment requires explanation. What you meant by it may be perfectly
> obvious to those who monitor comp.lang.javascript,

It should.

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

Yes, that only seems to be so.  The newsgroup name, charter and tagline are 
both historic considering what is being discussed there now (and rightly 
so), and the newsgroup name is case-insensitive as newsgroup names usually 
go.  (You would not talk about “c” either, would you?)
 
> The [0] seems to be intended as a cross-reference, but I couldn't locate
> it.

It was in my signature; the URI still is.
 
> 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;
  }

(Source code optimization could either add pretty printing or strip almost 
all whitespace.)

The “| 0” operation itself cannot be optimized away, but as I indicated it 
can be replaced for greater flexibility (and a closer-to-C/C++-int 
implementation).

F'up2 had been set.  Please stop cross-posting (without F'up2).

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

#45850

On 06/12/2014 08:45 AM, Thomas 'PointedEars' Lahn wrote:
> [F'up2 comp.lang.javascript]

Noted, and ignored. Explanation in last paragraph.

> James Kuyper wrote in comp.lang.c:
...
>> The [0] seems to be intended as a cross-reference, but I couldn't locate
>> it.
> 
> It was in my signature; the URI still is.

I've found it, but I don't think it was reasonable to have expected
someone to be able to find it there, without more of a clue about where
to look. I routinely ignore signatures, I suspect that this is
commonplace. My newsreader, like many, displays signatures in ways
designed to avoid drawing attention to them. Specifically, it displays
them in light grey text on a white background.

The corresponding link brings up a blank screen on my system, so I'm
still not sure what the cross-reference was intended to convey. From
your comments earlier, I assume it's something about the case. Is
Javascript better? Or should it be JavaScript?

> F'up2 had been set.  Please stop cross-posting (without F'up2).

The original question, and everything I've ever had to say about this
thread, has always been about whether the translation of a particular
example of C code to a particular bit of Javascript was correct. I don't
understand why you consider it inappropriate to cross-post such a
discussion to both a C oriented newsgroup and a Javascript oriented one.
I can't imagine a better case for cross-posting.
-- 
James Kuyper

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

#45854

James Kuyper <jameskuyper@verizon.net> wrote:

> The corresponding link brings up a blank screen on my system, so I'm
> still not sure what the cross-reference was intended to convey. From
> your comments earlier, I assume it's something about the case. Is
> Javascript better? Or should it be JavaScript?

My guess is that he wants to be called an EcmaScript(tm) Developer.

Richard

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

#45856

Richard Bos wrote:

> James Kuyper <jameskuyper@verizon.net> wrote:
>> The corresponding link brings up a blank screen on my system, so I'm
>> still not sure what the cross-reference was intended to convey. From
>> your comments earlier, I assume it's something about the case. Is
>> Javascript better? Or should it be JavaScript?
> 
> My guess is that he wants to be called an EcmaScript(tm) Developer.

Guess again.

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

#45872

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
> Richard Bos wrote:
>> James Kuyper <jameskuyper@verizon.net> wrote:
>>> The corresponding link brings up a blank screen on my system, so I'm
>>> still not sure what the cross-reference was intended to convey. From
>>> your comments earlier, I assume it's something about the case. Is
>>> Javascript better? Or should it be JavaScript?
>> 
>> My guess is that he wants to be called an EcmaScript(tm) Developer.
>
> Guess again.

I for one am not interested in guessing.

Your previous statement was:

    There is no javascript. [0]

You could save a great deal of time and effort by explaining what
you meant by that; one sentence would probably suffice.  Keep in
mind that a large part of the audience to which you made that
statement is not familiar with the language that is the main topic
of the comp.lang.javascript newsgroup (I hope that's sufficiently
unambiguous).

If you choose not to explain, that's fine with me; I'm sufficiently
interested to ask for clarification, but not to do further research.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#45875

Keith Thompson wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Richard Bos wrote:
>>> James Kuyper <jameskuyper@verizon.net> wrote:
>>>> The corresponding link brings up a blank screen on my system, so I'm
>>>> still not sure what the cross-reference was intended to convey. From
>>>> your comments earlier, I assume it's something about the case. Is
>>>> Javascript better? Or should it be JavaScript?
>>> My guess is that he wants to be called an EcmaScript(tm) Developer.
>> Guess again.
> 
> I for one am not interested in guessing.
> 
> Your previous statement was:
> 
>     There is no javascript. [0]
> 
> You could save a great deal of time and effort by explaining what
> you meant by that; one sentence would probably suffice.

Because it *certainly* would not, I used the footnote marker to refer to
my work.  However, unfortunately and unexpectedly, as of today there are 
technical issues that prevent it from being displayed.  So I have given some 
explanations in the postings in this thread.  You chose to ignore them or 
were impatient enough to wait for them arriving at your server.

That said, Google and several other Web caches still have a usable version 
of [0] <http://PointedEars.de/es-matrix>.  If that is still too hard for 
you, I could post the introduction here (in comp.lang.javascript).

> If you choose not to explain, that's fine with me; I'm sufficiently
> interested to ask for clarification, but not to do further research.

Translation: “I don't know and I don't care what you meant, but you are 
wrong.”

This has nothing to do with C.  Please stop crossposting (without F'up2).

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

#45876

Keith Thompson wrote:

> I for one am not interested in guessing.
> 
> Your previous statement was:
> 
>     There is no javascript. [0]
> 
> You could save a great deal of time and effort by explaining what
> you meant by that; one sentence would probably suffice.  Keep in
> mind that a large part of the audience to which you made that
> statement is not familiar with the language that is the main topic
> of the comp.lang.javascript newsgroup (I hope that's sufficiently
> unambiguous).

That is explained in the NG's FAQ[1] (emphasis mine):

| The comp.lang.javascript newsgroup deals with *ECMAScript languages*,
| so any questions about JavaScript or JScript are welcome.

In chapter 2 the FAQ says:

| The term "javascript" is used as a common name for all dialects of
| ECMAScript.

However, this statement is changed in the revised FAQ[2]:

| For historical reasons, the term “javascript” is used herein as a
| shorthand for “ECMAScript-based programming languages”. Note that not
| all uses of that term here are correct. For example, there are
| instances where using “DOM” instead would have been correct. This
| will be fixed in a later revision.

I agree that it is preferable to eschew the term "javascript" to avoid
potential confusion.

[1] <http://www.jibbering.com/faq/>
[2] <http://pointedears.de/scripts/faq/cljs/>

-- 
Christoph M. Becker

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

#45877

On 2014-06-12, Christoph Michael Becker <cmbecker69@arcor.de> wrote:
> Keith Thompson wrote:
>| For historical reasons, the term “javascript” is used herein as a
>| shorthand for “ECMAScript-based programming languages”. Note that not
>| all uses of that term here are correct. For example, there are
>| instances where using “DOM” instead would have been correct. This
>| will be fixed in a later revision.
>
> I agree that it is preferable to eschew the term "javascript" to avoid
> potential confusion.

monster.com search for "JavaScript":

  631 JavaScript jobs matched your search

monster.com search for "ECMAScript"

  *crickets*

careers.stackoverflow.com search for "JavaScript"

  932 jobs for "JavaScript"

careers.stackoverflow.com search for "ECMAScript"

  2 jobs for ECMAScript

It's safe to say that pretty much nobody in the real world gives a fuck about
"ECMAScript".

Brendan Eich: "ECMAScript was always an unwanted trade name that sounds like a
skin disease".

Amen.

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

#45879

Kaz Kylheku wrote:

> monster.com search for "JavaScript":
> 
>   631 JavaScript jobs matched your search
> 
> monster.com search for "ECMAScript"
> 
>   *crickets*
> 
> careers.stackoverflow.com search for "JavaScript"
> 
>   932 jobs for "JavaScript"
> 
> careers.stackoverflow.com search for "ECMAScript"
> 
>   2 jobs for ECMAScript
> 
> It's safe to say that pretty much nobody in the real world gives a fuck about
> "ECMAScript".

I somewhat agree.  That might be the reason for the poor quality of many
JavaScript programs in the wild.

> Brendan Eich: "ECMAScript was always an unwanted trade name that sounds like a
> skin disease".
> 
> Amen.

Fortunately, the name JavaScript is not only a wanted trade name, but
also avoids any confusion about JavaScript being a scripted variant of
Java. ;)

[xpost & fup2 comp.lang.javascript]

-- 
Christoph M. Becker

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

#45884

On 2014-06-12, Christoph Michael Becker <cmbecker69@arcor.de> wrote:
> Kaz Kylheku wrote:
>
>> monster.com search for "JavaScript":
>> 
>>   631 JavaScript jobs matched your search
>> 
>> monster.com search for "ECMAScript"
>> 
>>   *crickets*
>> 
>> careers.stackoverflow.com search for "JavaScript"
>> 
>>   932 jobs for "JavaScript"
>> 
>> careers.stackoverflow.com search for "ECMAScript"
>> 
>>   2 jobs for ECMAScript
>> 
>> It's safe to say that pretty much nobody in the real world gives a fuck about
>> "ECMAScript".
>
> I somewhat agree.  That might be the reason for the poor quality of many
> JavaScript programs in the wild.

Here is an issue. ECMAScript insinuates that the language is a standard
dialect. What do you call a dialect which consists of ECMAScript, plus
some implementation-specific extensions?

If you call that ECMAScript, it is misleading, because uses features that are
not described in any Ecma standard.

With a normal language name that doesn't incorporate a standards organization
acronym, we don't have a problem.

For instance we say that we are working in C++ (where most of othe code is
ISO C++, and parts are GNU C++).

The generic name C++ usefully refers to the whole family of dialects.

It is the case with numerous languages; Lisp, Fortran, Pascal, you name it.

As soon as you qualify the name with the name of a standards organization, like
"ISO C++", it cannot clearly refer to the dialect family any more.

In their feverish zeal to have a famous "Script" language named after
their god-forsaken organization, the Eurotards responsible for this farce
clearly didn't pause for a second to think a little bit.

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

#45887

Kaz Kylheku wrote:

> On 2014-06-12, Christoph Michael Becker <cmbecker69@arcor.de> wrote:
>
>> Kaz Kylheku wrote:
>>
>>> It's safe to say that pretty much nobody in the real world gives a fuck about
>>> "ECMAScript".
>>
>> I somewhat agree.  That might be the reason for the poor quality of many
>> JavaScript programs in the wild.
> 
> Here is an issue. ECMAScript insinuates that the language is a standard
> dialect.

Only to those who do not care to read the introduction of the language
specification[1].  And that is exactly the point: many who speak of
"javascript" do not even know, that there is a language specification.
It seems appropriate to make them aware.

>          What do you call a dialect which consists of ECMAScript, plus
> some implementation-specific extensions?

I'd call it a conforming ECMAScript implementation.

> If you call that ECMAScript, it is misleading, because uses features that are
> not described in any Ecma standard.

The ECMAScript standard explicitely allows such extensions in section 2.

> With a normal language name that doesn't incorporate a standards organization
> acronym, we don't have a problem.

If loosing clarity is not a problem.

> For instance we say that we are working in C++ (where most of othe code is
> ISO C++, and parts are GNU C++).
> 
> The generic name C++ usefully refers to the whole family of dialects.
> 
> It is the case with numerous languages; Lisp, Fortran, Pascal, you name it.

Lisp is a good example, as that spans Lisp 1.5 and Scheme (besides
others); two dialects (one may call it two languages) with rather
different semantics.  A program that runs on both dialects, could have
completely different outcome.  Would it be wise to ask: "I have a Lisp
program; can you please explain what it is doing?"

> As soon as you qualify the name with the name of a standards organization, like
> "ISO C++", it cannot clearly refer to the dialect family any more.

Unless otherwise defined, see above.

> In their feverish zeal to have a famous "Script" language named after
> their god-forsaken organization, the Eurotards responsible for this farce
> clearly didn't pause for a second to think a little bit.

You may consider catching up on JavaScript/ECMAScript's history before
making such claims.

[1] <http://www.ecma-international.org/ecma-262/5.1/>

-- 
Christoph M. Becker

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

#45896

Stefan Ram wrote:

> Christoph Michael Becker <cmbecker69@arcor.de> writes:
>> Lisp 1.5
> 
>   The LISP 1.5 programmer's manual (1962) writes the language
>   thus: »LISP«. (I am not sure whether you refer to that
>   language LISP 1.5, or whether »Lisp 1.5« is something else.)

Indeed, I wanted to refer to LISP 1.5.  Thanks for pointing out my mistake.

>   BTW, JavaScript is the scripting language of 
> 
>     - Mozilla (Netscape) (trademark used by permission of
>       Oracle (Sun)), and
> 
>     - Java SE 8 (trademark used by Oracle itself).
> 
>   I am not aware of any other party that has the permission
>   of Oracle to use »JavaScript« for a programming language.

As Thomas Lahn has already pointed out in this thread[1]:

| Of the ECMAScript implementations that I would consider “major”, there
| are Netscape/Mozilla JavaScript, Google V8 JavaScript and KDE
| JavaScript that contain the “JavaScript” name standalone. The original
| JavaScript, of course, is Netscape JavaScript, with Mozilla JavaScript
| as its open-source free-software successor (at least those parts that
| are licensed under MPL 2.0 or later). “Internet Explorer JavaScript”
| is just a Micro$~1 marketing scam; its real name is Microsoft JScript
| 9+ (codename “Chakra”), supported by MSHTML 9+.

I do not know if these parties have permission from Oracle to use the
name "JavaScript" for their implementations, but obviously they use it.

[1] <news:2396275.g7lyTkyHjg@PointedEars.de>

[xpost & fup2 comp.lang.javascript]

-- 
Christoph M. Becker

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

#45899

Stefan Ram wrote:

>   BTW, JavaScript is the scripting language of
> 
>     - Mozilla (Netscape) (trademark used by permission of
>       Oracle (Sun)), and

Correct, in a way.
 
>     - Java SE 8

How did you get that idea?

> (trademark used by Oracle itself).

Oracle Corp. *owns* the “JavaScript” trademark because they took over Sun 
Microsystems, Inc. which previously owned the “JavaScript” trademark because 
they previously already owned the “Java” trademark, and Sun owning the 
“JavaScript” trademark was one of the results of negotiations leading to a 
mutual agreement between Netscape Communications Corp. and Sun Microsystems, 
Inc. in December 1995 (CE).
 
>   I am not aware of any other party that has the permission
>   of Oracle to use »JavaScript« for a programming language.

Me neither.  But they do, and Oracle does not seem to mind; the same as Sun 
did not seem to mind when KDE e.V. (“KDE JavaScript (KJS)”, 2000), Apple 
Inc. (“JavaScriptCore”, based on KJS; 2003), the WebKit Open Source Project 
(ditto, 2005), Google Inc. (“V8 JavaScript”, 2008), and even Microsoft Corp. 
(“Internet Explorer JavaScript”, 2011) started using it¹.

____________
¹ Opera has always been ambiguous; they have used both the “ECMAScript”
  and the “JavaScript” name to refer to their implementation, which is
  why I am using the term “Opera ECMAScript”.  They have adopted V8
  last year, so what applies to Google now also applies to them.
-- 
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]

#45993 — ECMAScript standards (was: "i = i|0")

[F'up2 comp.lang.javascript]

Stefan Ram wrote in comp.lang.c and comp.lang.javascript:

> Christoph Michael Becker <cmbecker69@arcor.de> writes:
>> Only to those who do not care to read the introduction of the language
>> specification[1].  And that is exactly the point: many who speak of
>> [...]
>> [1] <http://www.ecma-international.org/ecma-262/5.1/>
> 
>       »The nice thing about standards is that you have so many to choose
>       from.«
>     Andrew Stuart Tanenbaum
> 
>       »ISO/IEC 16262:2011 defines the ECMAScript scripting language.«
>     International Organization for Standardization

ISO/IEC 16262:2011 is just the ISO/IEC version of ECMA-262-5.1 [1], which is 
the current Edition that is implemented by current versions of script 
engines.   Some engines also implement features specified in the upcoming 
ECMA-262-6. [2][3]  (This is not peculiar.  ISO/IEC 15445:2000(E) is the 
ISO/IEC version of HTML 4.0.  Current Web browsers implement HTML5.  There 
are many C compilers, but only one ANSI/ISO C.)

Usenet is organized into groups of topics.  Please stop crossposting to 
where it is off-topic.  Please set Followup-To (F'up2) to where it is
on-topic.  Please update the Subject header field as shown if the subject of 
discussion changes.

___________
[1] <http://wiki.ecmascript.org/doku.php>
[2] <http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts>
[3] <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference#Keyed_collections>
-- 
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]

#45994 — Re: ECMAScript standards (was: "i = i|0")

On Sunday, June 15, 2014 11:53:46 AM UTC+1, Thomas 'PointedEars' Lahn wrote:
> [F'up2 comp.lang.javascript]
> 
> Stefan Ram wrote in comp.lang.c and comp.lang.javascript:
> 
> 
> > Christoph Michael Becker <cmbecker69@arcor.de> writes:
> >> Only to those who do not care to read the introduction of the language
> >> specification[1].  And that is exactly the point: many who speak of
> >> [...]
> 
> >> [1] <http://www.ecma-international.org/ecma-262/5.1/>
> 

> >       »The nice thing about standards is that you have so many to choose
> >       from.«
> >     Andrew Stuart Tanenbaum
> 
>
> >       »ISO/IEC 16262:2011 defines the ECMAScript scripting language.«
> >     International Organization for Standardization
>
> ISO/IEC 16262:2011 is just the ISO/IEC version of ECMA-262-5.1 [1], which is 
> the current Edition that is implemented by current versions of script 
> engines.   Some engines also implement features specified in the upcoming 
> ECMA-262-6. [2][3]  (This is not peculiar.  ISO/IEC 15445:2000(E) is the 
> ISO/IEC version of HTML 4.0.  Current Web browsers implement HTML5.  There 
> are many C compilers, but only one ANSI/ISO C.)
> 
> 
Help.
The only real response to a alphabet soup of standards is to be very conservative, alternatively
target only one particular browser, and hope that things eventually settle down.

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

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

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

csiph-web