Call a function syntax

I am trying to understand a piece of code. In a javascrpit file,
there is a function:

function ItemStyle(){
var names=['len','spacing','popInd','popPos','pad','outCol',' overCol','outClass','overClass','outBorder','overB order','outAlpha','overAlpha','normCursor','nullCu rsor'];
addProps(this,arguments,names,true);
};

In the html file, it calls the function as:

var hBar = new ItemStyle(40, 10, '', 0, 0, '10#336699', '10#6699CC',
'highText', 'highText', '', '',
null, null, 'hand', 'default');

How can it pass the 15 arguments to the function when the function
does not have parameters?

re: Call a function syntax

> How can it pass the 15 arguments to the function when the function[color=blue]
> does not have parameters?[/color]

You don't have to formally declare the arguments of JavaScript
functions if you don't want to. They are passed in the 'arguments'
array.

re: Call a function syntax

chirs said:[color=blue]
>
>I am trying to understand a piece of code. In a javascrpit file,
>there is a function:
>
>function ItemStyle(){
>var
>names=['len','spacing','popInd','popPos','pad','outCol',' overCol','outClass','overClass','outBorder','overB order','outAlpha','overAlpha','normCursor','nullCu rsor'];
>addProps(this,arguments,names,true);
>};
>
>In the html file, it calls the function as:
>
>var hBar = new ItemStyle(40, 10, '', 0, 0, '10#336699', '10#6699CC',
>'highText', 'highText', '', '',
> null, null, 'hand', 'default');
>
>How can it pass the 15 arguments to the function when the function
>does not have parameters?[/color]

The "arguments" attribute of the function (seen as a local variable
within the function) is the array of arguments passed to it.

re: Call a function syntax

Graham J wrote:
[color=blue][color=green]
>> How can it pass the 15 arguments to the function when the function
>> does not have parameters?[/color]
>
> You don't have to formally declare the arguments of JavaScript
> functions if you don't want to. They are passed in the 'arguments'
> array.[/color]

Although it is described in the Core Reference as such and you can
access its properties like the elements of an array (using the index
operator), I would not call it an array, since it is lacking features
of the Array prototype, like the join(...) method, and would call it
a collection instead.


PointedEars

re: Call a function syntax

> >> How can it pass the 15 arguments to the function when the function[color=blue][color=green][color=darkred]
> >> does not have parameters?[/color]
> >
> > You don't have to formally declare the arguments of JavaScript
> > functions if you don't want to. They are passed in the 'arguments'
> > array.[/color]
>
> Although it is described in the Core Reference as such and you can
> access its properties like the elements of an array (using the index
> operator), I would not call it an array, since it is lacking features
> of the Array prototype, like the join(...) method, and would call it
> a collection instead.[/color]

Strictly speaking, this is correct. The nature of the arguments object was a
Netscape error that Microsoft copied and put into the ECMAScript standard. There
are many errors in the standard. ECMA is a substandard standards organization.

The arguments object has a length member, but in all other respects it is just
an object. I use

var a = Array.prototype.slice.apply(arguments);

to turn it into a genuine array.

http://www.crockford.com/javascript/remedial.html

re: Call a function syntax

Douglas Crockford wrote:

Who wrote this? Please include an attribution line.
vvvvvvvvvvvvvvv[color=blue][color=green][color=darkred]
>> >> How can it pass the 15 arguments to the function when the function
>> >> does not have parameters?
>> >
>> > You don't have to formally declare the arguments of JavaScript
>> > functions if you don't want to. They are passed in the 'arguments'
>> > array.[/color]
>>
>> Although it is described in the Core Reference as such and you can
>> access its properties like the elements of an array (using the index
>> operator), I would not call it an array, since it is lacking features
>> of the Array prototype, like the join(...) method, and would call it
>> a collection instead.[/color]
>
> Strictly speaking, this is correct. The nature of the arguments object was a
> Netscape error that Microsoft copied and put into the ECMAScript standard.[/color]

An `arguments array' is not specified in ECMAScript 3, but
the `arguments object' is (in sections 10.1.6 and 10.1.8.)
[color=blue]
> There are many errors in the standard.[/color]

Such as? I was writing about Netscape's Core JavaScript 1.5
Reference at DevEdge, not ECMAScript (Ed. 3).
[color=blue]
> ECMA is a substandard standards organization.[/color]

Hm?

"Ecma International is an industry association founded in 1961,
dedicated to the standardization of information and communication
systems." (http://ecma-international.org/)


PointedEars

re: Call a function syntax

> >> Although it is described in the Core Reference as such and you can[color=blue][color=green][color=darkred]
> >> access its properties like the elements of an array (using the index
> >> operator), I would not call it an array, since it is lacking features
> >> of the Array prototype, like the join(...) method, and would call it
> >> a collection instead.[/color]
> >
> > Strictly speaking, this is correct. The nature of the arguments object was a
> > Netscape error that Microsoft copied and put into the ECMAScript standard.[/color]
>
> An `arguments array' is not specified in ECMAScript 3, but
> the `arguments object' is (in sections 10.1.6 and 10.1.8.)
>[color=green]
> > There are many errors in the standard.[/color]
>
> Such as? I was writing about Netscape's Core JavaScript 1.5
> Reference at DevEdge, not ECMAScript (Ed. 3).[/color]

Errors in the language design: The arguments array is not an array. Reserved
words cannot be used as names in the object literal notation. Reserved words
cannot be used in dot notation. '+' does type coersion to string in some cases.
typeof null == 'object'. Excess function parameters are ignored. 'this' is set
to the global object when calling inner functions. A leading '0' may or may not
be interpreted as octal. 'undefined' can be redefined. The 'width' statement can
sometimes clobber members of the global object.

The Specification itself suffers from being at the wrong level of detail. It is
at once too vague and too implementation specific. Worst of all, it is very
difficult to read and understand.
[color=blue][color=green]
> > ECMA is a substandard standards organization.[/color]
>
> Hm?
>
> "Ecma International is an industry association founded in 1961,
> dedicated to the standardization of information and communication
> systems." (http://ecma-international.org/)[/color]

ECMA issued the ECMAScript Language Specification, which is a poorly written
specification which requires complying implementation to intentionally repeat
the mistakes from the first implementations. Generally, real standard bodies
have attempted where possible to correct or at least deprecate past mistakes.

Netscape chose ECMA because they thought that, being a light-weight
organization, they would be easy to push around. Netscape should not have been
seeking a standard at that point in time because the language was too immature.
ECMA wanted the business, so a substandard standard was produced.

On balance, ECMAScript works much better as a standard than web browsers. W3C
makes ECMA look like a Class Act, but that's another story.

http://www.crockford.com/javascript/javascript.html

re: Call a function syntax

"Douglas Crockford" <nospam@covad.net> writes:
[color=blue]
> Errors in the language design: The arguments array is not an
> array.[/color]

Are we sure we want it to be?

If you had the function
function foo(b,c) {
arguments.length = b;
alert(c);
}
and you call it as
foo(1,"bar");
what should happen?

If "arguments" is an array, then "c" should become undefined. If not,
it is still "bar".

I would prefer the arguments object to be just an object, and the
length property to be read only.
[color=blue]
> Reserved words cannot be used as names in the object literal
> notation. Reserved words cannot be used in dot notation.[/color]

That's a matter of taste. I prefer keywords to be restricted. It makes
programs easier to read if "if" means the same everywhere.
They should drop all the reserved words that are not keywords, though.
[color=blue]
> '+' does type coersion to string in some cases. typeof null ==
> 'object'.[/color]

A Java-ism, definitly. I would drop "null" completely. We don't need
both undefined and null.
[color=blue]
> Excess function parameters are ignored.[/color]

I like that (and I'm not sure whether you mean that you can send too
few or too many arguments to a function). I definitly don't think
it's an error.
[color=blue]
> 'this' is set to the global object when calling inner functions.[/color]

Bad desing. Agree completely! Highly annoying.
[color=blue]
> A leading '0' may or may not be interpreted as octal. 'undefined'
> can be redefined.[/color]

So can Infinity and NaN. They should all be keywords like "true and
"false"
[color=blue]
> The 'width' statement can sometimes clobber members of the global
> object.[/color]

"with" :).
I wouldn't know, I never use it :)
[color=blue]
> The Specification itself suffers from being at the wrong level of
> detail. It is at once too vague and too implementation
> specific. Worst of all, it is very difficult to read and understand.[/color]

Hear, hear!

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

re: Call a function syntax

Douglas Crockford wrote:
^^^^^^^^^^^^^^^^^^^^^^^^^
Attribution line, please!
vvvvvvvvvvvvvvvvvvvvvvvvv[color=blue][color=green][color=darkred]
>> >> Although it is described in the Core Reference as such and you can
>> >> access its properties like the elements of an array (using the index
>> >> operator), I would not call it an array, since it is lacking features
>> >> of the Array prototype, like the join(...) method, and would call it
>> >> a collection instead.
>> >
>> > Strictly speaking, this is correct. The nature of the arguments object was a
>> > Netscape error that Microsoft copied and put into the ECMAScript standard.[/color]
>>
>> An `arguments array' is not specified in ECMAScript 3, but
>> the `arguments object' is (in sections 10.1.6 and 10.1.8.)
>>[color=darkred]
>> > There are many errors in the standard.[/color]
>>
>> Such as? I was writing about Netscape's Core JavaScript 1.5
>> Reference at DevEdge, not ECMAScript (Ed. 3).[/color]
>
> Errors in the language design: The arguments array is not an array.[/color]

What part of

| An `arguments array' is not specified in ECMAScript 3, but
| the `arguments object' is (in sections 10.1.6 and 10.1.8.)

do I need to spell for you? ECMAScript is the standard when
it comes to JavaScript, and nothing else.
[color=blue]
> Reserved words cannot be used as names in the object literal notation.
> Reserved words cannot be used in dot notation.[/color]

That is why they are called `_reserved_ words'!
[color=blue]
> '+' does type coersion to string in some cases.[/color]

That is a feature, not an error in language design. It is, however, an
error in your code based on a false assumption. JavaScript 1.x is a
*weak* typed language by design, and `+' is the concatenation operator
for string values. If you watch the operator precedence and type of
operands, with a working ECMAScript implementation you will get no
unexpected behavior.
[color=blue]
> typeof null == 'object'.[/color]

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

Since a reference points to an object, what other
type would you choose for `null' than `object'?
[color=blue]
> Excess function parameters are ignored.[/color]

-v
[color=blue]
> 'this' is set to the global object when calling inner functions.[/color]

What are `inner functions'?

That `this' points to the top-level object in functions that are not
called with the lookup operator is a feature, not a bug. Only what I
find disturbing is that there is no way to refer to the global object
directly, independent of the context.
[color=blue]
> A leading '0' may or may not be interpreted as octal.[/color]

But not by chance. There are rules that define
when it is interpreted as octal and when not.
[color=blue]
> 'undefined' can be redefined.[/color]

And?
[color=blue]
> The 'width' statement can sometimes clobber members of the global object.[/color]

There is no `width' statement. You probably mean the `with' statement
which is considered bad practice in several languages (Zend developers
even refuse to implement it because of the ambiguity that would evolve
then in PHP code). Besides, there are errors in implementations of
ECMAScript, especially in IE's JScript.
[color=blue]
> The Specification itself suffers from being at the wrong level of detail.
> It is at once too vague and too implementation specific.[/color]

That is merely a statement, where is the proof?

I fail to find implementation-specific parts in ECMAScript and since
ECMAScript is a language to be implemented, the specification is
required to be this way.
[color=blue]
> Worst of all, it is very difficult to read and understand.[/color]

A specification of a programming language is a work of science
for implementors, it is not designed to be easily readable and
understandable for the average programmer. There are the
JavaScript Guide, Reference, MSDN and other documentation
available to serve that purpose. Perhaps you should stick to
that if ECMAScript is to complicated for you.
[color=blue][color=green][color=darkred]
>> > ECMA is a substandard standards organization.[/color]
>>
>> Hm?
>>
>> "Ecma International is an industry association founded in 1961,
>> dedicated to the standardization of information and communication
>> systems." (http://ecma-international.org/)[/color]
>
> ECMA issued the ECMAScript Language Specification, which is a poorly written
> specification which requires complying implementation to intentionally repeat
> the mistakes from the first implementations. Generally, real standard bodies
> have attempted where possible to correct or at least deprecate past mistakes.[/color]

How the heck did you get that idea? Netscape invented the JavaScript
language and used its Associate Membership(!) in ECMA to standardize
most of JavaScript user agent independent features as ECMAScript.
However, Netscape continued (and is still continuing) to develop
JavaScript. After M$ finally found out that there is a Web out there,
they took elements from ECMAScript and the current JavaScript version
of these days mixed with own extensions and created JScript. In fact,
Netscape is revising JavaScript versions which later become ECMAScript
specifications for the most part. ECMAScript 3, where some features of
previous versions are in fact deprecated, is based upon JavaScript as
supported in Mozilla/5.0 or you can say JavaScript 1.5 as supported in
Mozilla/5.0 is an implementation of ECMAScript 3. JavaScript 2.0 will
be standardized as ECMAScript 4, the proposal is already underway.

And, please forgive my ignorance, what do you mean by "real standard
bodies"?
[color=blue]
> Netscape chose ECMA because they thought that, being a light-weight
> organization, they would be easy to push around. Netscape should not have been
> seeking a standard at that point in time because the language was too immature.
> ECMA wanted the business, so a substandard standard was produced.[/color]

Sounds like M$ propaganda.
[color=blue]
> http://www.crockford.com/javascript/javascript.html[/color]

I have never read such a load of FUD crap.


PointedEars

re: Call a function syntax

On Mon, 24 Nov 2003 02:39:20 +0100
Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:
<snip>[color=blue]
> What are `inner functions'?[/color]

Functions defined inside other, "outer", functions.
<snip>[color=blue]
>[color=green]
> > http://www.crockford.com/javascript/javascript.html[/color]
>
> I have never read such a load of FUD crap.[/color]

Thomas, I don't want to tangle with you, but I have noticed that you are
quick to judgement, tactless, and more often wrong than right. Just
exactly what on that site do you consider FUD?


--
Then there was the man who drowned crossing a stream with an average
depth of six inches.
-- W. I. E. Gates

re: Call a function syntax

Albert Wagner wrote:
[color=blue]
> Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote:[color=green][color=darkred]
>> > http://www.crockford.com/javascript/javascript.html[/color]
>>
>> I have never read such a load of FUD crap.[/color]
>
> [...] Just exactly what on that site do you consider FUD?[/color]

Take the ECMA stuff for example:

| JavaScript, aka Mocha, aka LiveScript, aka JScript, aka ECMAScript,
| is one of the world's most popular programming languages.

JavaScript is _not_ ECMAScript, it is and has always been,
Netscape(/AOLTW)'s implementation of the latter.[1] JScript
is *neither* JavaScript *nor* ECMAScript, it is *Microsoft's*
implementation of ECMAScript, as one could have also read in
the FAQ of this NG.[2]

AFAIS, Mocha is a Java decompiler[3] and such has nothing to
do with ECMAScript, JavaScript or other implementations of the
former at all.

| The ECMA committee that has stewardship over the language is developing
| extensions which, while well intentioned, will aggravate one of the
| language's biggest problems: There are already too many versions.
| This creates confusion.

ECMA does neither watch over JavaScript nor does it develop extensions
for it. ECMA International, as an "industry association [...] dedicated
to the standardization of information and communication systems[...]"[4]
where also Netscape/AOLTW and Microsoft are members of[5], watches over
ECMAScript. There are exactly 3 versions/editions of ECMAScript or
ECMA-262 right now: ECMAScript (Ed. 1), ECMAScript (Ed.) 2 and
ECMAScript 3, while only the first and the third are widely
implemented[6] (and only the third being available for download now[7]).
There are six JavaScript versions until now: JavaScript 1.0, JavaScript
1.1, JavaScript 1.2, JavaScript 1.3, JavaScript 1.4 and JavaScript 1.5.
Of those, versions other than 1.4 are implemented in Netscape browsers
(1.4 being implemented along with other versions as server-side
JavaScript in versions of the Netscape Enterprise Server; 1.5 in all
Mozilla/5.0 based browsers incl. Netscape 6+) and versions other than
1.2 are fully compatible with ECMAScript.[1] JavaScript 2.0 as
developed by Waldemar Horwat at Netscape/AOLTW is likely to become an
implementation of ECMAScript 4, currently implemented in Epimetheus only.[8]

Other implementations of ECMAScript include different versions of
Microsoft JScript, supported in M$ Internet Explorer and UAs that
use the IE browser component.[9]

| The design of the language on the whole is quite sound. Surprisingly,
| the ECMAScript committee does not appear to be interested in
| correcting these problems. Perhaps they are more interested in making
| new ones.

Quite sound to whom? What a problem must the author have with "evil"
ECMA not following his misguided attempts to tell us that

| JavaScript's C-like syntax, including curly braces and the clunky for
| statement, makes it appear to be an ordinary procedural language. This
| is misleading because JavaScript has more in common with functional
| languages like Lisp or Scheme than with C or Java.

Because it allows for closures, currying and anonymous functions? OMG.
Obviously the author has never found (or did not wanted to find?) time
to read the ECMAScript specification thoroughly (see below.)

| The official specification for the language is published by ECMA.

Wrong. The official specification for _ECMAScript_ is published by
ECMA. The official specification for JavaScript, if you can call the
Client-Side/Server-Side/Core JavaScript Guide and Reference this, is
published and has always been published by Netscape(/AOLTW) as *they*
are to implement ECMAScript as JavaScript.

| The specification is of extremely poor quality. It is difficult to
| read, and very difficult to understand.

Because the author is unable to read technical specifications, they must
be "of extremely poor quality." Well, there are at least two people (I
assume of one that he does because of his statements in this newsgroup)
that find it very well put and of good quality as recent research on
grammar productions has (again) proven.[10]

| This has been a contributor to the Bad Book problem because authors
| have been unable to use the standard document to improve their own
| understanding of the language.

As said before[11], technical specifications of programming languages to
be implemented are never meant to be understood easily by the average
programmer. They provide rules which implementors should obey if they
want to call their implementation conforming to one of the described
programming language.[12]

| ECMA and the TC39 committee should be deeply embarrassed.

Again an attempt of FUD only because the author lacks understanding
of the purpose of the specification and ECMAScript in general.


PointedEars
___________
[1]
http://devedge.netscape.com/library/...o.html#1013654
http://jibbering.com/faq/#FAQ2_6
[2] http://jibbering.com/faq/#FAQ2_7
[3] http://google.com/search?q=Mocha&filter=0
[4] http://www.ecma-international.org/
[5] http://www.ecma-international.org/memento/associat.htm
http://www.ecma-international.org/memento/ordinary.htm
[6]
http://devedge.netscape.com/library/...e.html#1003515
[7] http://www.ecma-international.org/pu...s/Ecma-262.htm
[8] http://mozilla.org/js/language/
[9]
http://msdn.microsoft.com/library/de...oriJScript.asp
[10] <news:bpj08v$1pmhf0$14@ID-107532.news.uni-berlin.de>
[11] <news:3FC16148.7060708@PointedEars.de>
[12] ECMAScript Ed. 3, Page 1:

| 1 Scope
|
| This Standard defines the ECMAScript scripting language.
|
|
| 2 Conformance
|
| A conforming implementation of ECMAScript must provide [...]
|
| A conforming implementation of this International standard shall
| interpret [...]
|
| A conforming implementation of ECMAScript is permitted to provide
| [...]
|
| A conforming implementation of ECMAScript is permitted to support
| [...]
|
|
| 3 Normative References
| [...]

re: Call a function syntax

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
[color=blue]
> Take the ECMA stuff for example:
>
> | JavaScript, aka Mocha, aka LiveScript, aka JScript, aka ECMAScript,
> | is one of the world's most popular programming languages.
>
> JavaScript is _not_ ECMAScript, it is and has always been,
> Netscape(/AOLTW)'s implementation of the latter.[1] JScript
> is *neither* JavaScript *nor* ECMAScript, it is *Microsoft's*
> implementation of ECMAScript, as one could have also read in
> the FAQ of this NG.[2][/color]

You are looking at his survey page. It is not intended as exact informatio
[color=blue]
>
> AFAIS, Mocha is a Java decompiler[3] and such has nothing to
> do with ECMAScript, JavaScript or other implementations of the
> former at all.[/color]

.... and you are wrong:
<URL:http://www.mozilla.org/classic/libmdesc.html>
These are equivalent when written in the address bar of Netscape 4:
mocha:alert("X");
javascript:alert("X");
livescript:alert("X");

So, Javascript aka. Livescript aka. Mocha is correct.

When you write
<script type="text/javascript">
IE interprets the content using its JScript interpreter.
It is fair to say that JScript is also known as Javascript,
so Javascript aka. JScript is correct.

What is the language implemented by Opera?
They call it Javascript. It differs from Netscape's Javascript.
It implements ECMAScript v3 + extensions.
What is it?

The word "Javascript" long ago stopped only referring to Netscape's
brand of ECMAScript. It is now, like Kleenex, a common word used about
similar products from other compagnies.

The one you can split hairs about is ECMAScript. There is no language
called ECMAScript, only a specification. There are languages with
other names impelementing this specification. At least, that's one way
to see it.
Another is to say that Javascript is ECMAScript (plus som more). And
that Javascript Core *is* ECMAScript.
People rutinely refer to ECMASCript as the standard for Javascript.
It is somewhat fair to say that ECMAScript is also known as Javascript.

Most people don't make a difference between the various ECMAScript
implementations.
[color=blue]
> | The ECMA committee that has stewardship over the language is developing
> | extensions which, while well intentioned, will aggravate one of the
> | language's biggest problems: There are already too many versions.
> | This creates confusion.
>
> ECMA does neither watch over JavaScript nor does it develop extensions
> for it. ECMA International, as an "industry association [...] dedicated
> to the standardization of information and communication systems[...]"[4]
> where also Netscape/AOLTW and Microsoft are members of[5], watches over
> ECMAScript.[/color]
....

So, ECMA is not making the changes, the compagnies that are members of
it does. Fair. If ECMA is accepting anything Netscape Corp. creates
without looking at it, then I also agree that ECMA is not a very
good standards institution. If anything can be made standard, then
you have no qulaity guarantee.
[color=blue]
> | The design of the language on the whole is quite sound. Surprisingly,
> | the ECMAScript committee does not appear to be interested in
> | correcting these problems. Perhaps they are more interested in making
> | new ones.
>
> Quite sound to whom? What a problem must the author have with "evil"
> ECMA not following his misguided attempts to tell us that[/color]

WEll, only he can know that. I guess he thinks there were some bad desing
choices when Javascript was developed (and I agree with some of them).
He calls them "errors", which you seem to take literally.

Obviously you can find the places in the specification that says that
what he considers errors, is in fact required by the specification.
He thinks the specification should be (or rather: should have been)
changed.
[color=blue]
> | JavaScript's C-like syntax, including curly braces and the clunky for
> | statement, makes it appear to be an ordinary procedural language. This
> | is misleading because JavaScript has more in common with functional
> | languages like Lisp or Scheme than with C or Java.
>
> Because it allows for closures, currying and anonymous functions?[/color]

Yes (except currying, unless you use that for the ability to return a
function), and prototypical object inheritance.

And I agree.

If Javascript/ECMAScript had tail recursion, you could program
functional programs in it.
[color=blue]
> OMG.
> Obviously the author has never found (or did not wanted to find?) time
> to read the ECMAScript specification thoroughly (see below.)[/color]

Oh, I'm pretty sure he has. The page you are reading from is not
an objective review of the language. It is giving a subjective opinion
about the state of ECMAScript implementations in general and the
standard in particular.
[color=blue]
> | The official specification for the language is published by ECMA.
>
> Wrong. The official specification for _ECMAScript_ is published by
> ECMA.[/color]

ECMAScript aka. Javscript (Core). Yes.
[color=blue]
> The official specification for JavaScript, if you can call the
> Client-Side/Server-Side/Core JavaScript Guide and Reference this,[/color]

You can't. It is far from being specific enough to being a
specification. It is, at best, a manual.
[color=blue]
> is published and has always been published by Netscape(/AOLTW) as
> *they* are to implement ECMAScript as JavaScript.[/color]

[color=blue]
> | The specification is of extremely poor quality. It is difficult to
> | read, and very difficult to understand.
>
> Because the author is unable to read technical specifications, they must
> be "of extremely poor quality." Well, there are at least two people (I
> assume of one that he does because of his statements in this newsgroup)
> that find it very well put and of good quality as recent research on
> grammar productions has (again) proven.[10][/color]

It is very *thorough*. I *don't* think it is very well structured.
I much prefer "the Revised^4 Report on the Algorithmic Language Scheme"
("R4RS", <URL:http://www.swiss.ai.mit.edu/~jaffer/r4rs_toc.html>) or
"the Definition of Standard ML (Revised)"
(<URL:http://www.diku.dk/forskning/topps/activities/kit2/def97.html>)
Neither have, ofcourse, gone through a standards body.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

re: Call a function syntax

Lasse Reichstein Nielsen wrote:
[color=blue]
> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:[color=green]
>> Take the ECMA stuff for example:
>>
>> | JavaScript, aka Mocha, aka LiveScript, aka JScript, aka ECMAScript,
>> | is one of the world's most popular programming languages.
>>
>> JavaScript is _not_ ECMAScript, it is and has always been,
>> Netscape(/AOLTW)'s implementation of the latter.[1] JScript
>> is *neither* JavaScript *nor* ECMAScript, it is *Microsoft's*
>> implementation of ECMAScript, as one could have also read in
>> the FAQ of this NG.[2][/color]
>
> You are looking at his survey page. It is not intended as exact informatio[/color]

That was what he appended to his posting following his
"argumentation" and what we are discussion about.
[color=blue][color=green]
>> AFAIS, Mocha is a Java decompiler[3] and such has nothing to
>> do with ECMAScript, JavaScript or other implementations of the
>> former at all.[/color]
>
> .... and you are wrong:[/color]

I just did not *see*/tested unregistered URI schemes and relied on
friend Google.
[color=blue]
> <URL:http://www.mozilla.org/classic/libmdesc.html>
> These are equivalent when written in the address bar of Netscape 4:
> mocha:alert("X");
> javascript:alert("X");
> livescript:alert("X");
>
> So, Javascript aka. Livescript aka. Mocha is correct.[/color]

Mozilla/5.0 including Netscape 6+ implements JavaScript 1.5 and I get

| mocha is not a registered protocol.

`livescript:alert("bla")' does nothing, interestingly.

So I say: It is incorrect. See the point?
[color=blue]
> When you write
> <script type="text/javascript">
> IE interprets the content using its JScript interpreter.[/color]

No, it interprets what is similar to JavaScript with its script
interpreter. AFAIK that is not a JScript interpreter but one
that knows also VBScript, part of the Windows Script Host.
[color=blue]
> It is fair to say that JScript is also known as Javascript,
> so Javascript aka. JScript is correct.[/color]

It is incorrect, JScript is _not_ JavaScript.
[color=blue]
> What is the language implemented by Opera?
> They call it Javascript. It differs from Netscape's Javascript.
> It implements ECMAScript v3 + extensions.
> What is it?[/color]

It is Opera's implementation of ECMAScript, and they falsely call
it JavaScript.
[color=blue]
> The word "Javascript" long ago stopped only referring to Netscape's
> brand of ECMAScript. It is now, like Kleenex, a common word used about
> similar products from other compagnies.[/color]

Most people call `Internet' now what is in fact the World Wide Web,
a software application of and for the hardware Internet. People
call many things by the wrong name because they cannot or refuse to
understand that this makes a difference.
[color=blue]
> The one you can split hairs about is ECMAScript. There is no language
> called ECMAScript, only a specification.[/color]

ECMAScript is a (programming) language, and its specification proves
that before its page #1. Brainfuck, Blank and stuff like that are
programming languages, too. They do not need to be (widely) implemented
to be it.
[color=blue]
> There are languages with other names impelementing this specification.
> At least, that's one way to see it.[/color]

There are languages which implement features of (the) ECMAScript (language).
[color=blue]
> Another is to say that Javascript is ECMAScript (plus som more).
> And that Javascript Core *is* ECMAScript.[/color]

No, it is not.
[color=blue]
> People rutinely refer to ECMASCript as the standard for Javascript.[/color]

You are again being pointless, see above.
[color=blue]
> It is somewhat fair to say that ECMAScript is also known as Javascript.
>
> Most people don't make a difference between the various ECMAScript
> implementations.[/color]

See above.
[color=blue][color=green]
>> | The ECMA committee that has stewardship over the language is developing
>> | extensions which, while well intentioned, will aggravate one of the
>> | language's biggest problems: There are already too many versions.
>> | This creates confusion.
>>
>> ECMA does neither watch over JavaScript nor does it develop extensions
>> for it. ECMA International, as an "industry association [...] dedicated
>> to the standardization of information and communication systems[...]"[4]
>> where also Netscape/AOLTW and Microsoft are members of[5], watches over
>> ECMAScript.[/color]
> ....
>
> So, ECMA is not making the changes, the compagnies that are members of
> it does.[/color]

But regarding their implementations not in their function as member, but
for themselves.
[color=blue]
> Fair. If ECMA is accepting anything Netscape Corp. creates
> without looking at it,[/color]

They do not and I have never written that.
[color=blue]
> then I also agree that ECMA is not a very good standards institution.
> If anything can be made standard, then you have no qulaity guarantee.[/color]

See above.
[color=blue]
> Obviously you can find the places in the specification that says that
> what he considers errors, is in fact required by the specification.
> He thinks the specification should be (or rather: should have been)
> changed.[/color]

I already know what he "thinks", but I cannot agree with it. As he
tries to impose his opinion on others referring to the document, and I
was asked to tell what I find wrong about it, I answered the question
and stated my case.
[color=blue][color=green]
>> | JavaScript's C-like syntax, including curly braces and the clunky for
>> | statement, makes it appear to be an ordinary procedural language. This
>> | is misleading because JavaScript has more in common with functional
>> | languages like Lisp or Scheme than with C or Java.
>>
>> Because it allows for closures, currying and anonymous functions?[/color]
>
> Yes (except currying, unless you use that for the ability to return a
> function), and prototypical object inheritance.
>
> And I agree.
>
> If Javascript/ECMAScript had tail recursion, you could program
> functional programs in it.[/color]

And if my grandma had wheels, she would be a motorcycle.
[color=blue][color=green]
>> OMG.
>> Obviously the author has never found (or did not wanted to find?) time
>> to read the ECMAScript specification thoroughly (see below.)[/color]
>
> Oh, I'm pretty sure he has.[/color]

I am pretty sure he has not. What is stated about the execution
of statements does not fit to a functional language at all.
[color=blue]
> The page you are reading from is not an objective review of the
> language. It is giving a subjective opinion about the state of
> ECMAScript implementations in general and the standard in
> particular.[/color]

Exactly and that is why I call it "a load of FUD crap" when someone
tries to argument with it.
[color=blue][color=green]
>> | The official specification for the language is published by ECMA.
>>
>> Wrong. The official specification for _ECMAScript_ is published by
>> ECMA.[/color]
>
> ECMAScript[/color]

Yes.
[color=blue]
> aka. Javscript (Core). Yes.[/color]

No.
[color=blue][color=green]
>> The official specification for JavaScript, if you can call the
>> Client-Side/Server-Side/Core JavaScript Guide and Reference this,[/color]
>
> You can't. It is far from being specific enough to being a
> specification. It is, at best, a manual.[/color]

You note the `if'? So if you state that the Guide and Reference is
not a JavaScript specification, then ECMAScript cannot be a JavaScript
specification, too, since Netscape's JavaScript as described in the
Guide and Reference has been always a superset of ECMAScript. So there
is no JavaScript specification at all.


PointedEars

re: Call a function syntax

In article <2eb1b$3fc0f762$44a4afcc$3501@msgid.meganewsserver s.com>,
Douglas Crockford <nospam@covad.net> writes
<snip>[color=blue]
>ECMA is a substandard standards organization.[/color]
<snip>

ECMA is a European Computer Manufacturers Association, not a standards
organisation. It's produced a lot of standards, some of them very
useful, but they don't all have to be good for people who aren't large
computer companies.

John
--
John Harris

re: Call a function syntax

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
[color=blue]
> Lasse Reichstein Nielsen wrote:[/color]
[color=blue]
> I just did not *see*/tested unregistered URI schemes and relied on
> friend Google.[/color]

That's where I found the information. I had never heard of Mocha or
mocha: and livescript: schemas before.
[color=blue][color=green]
>> So, Javascript aka. Livescript aka. Mocha is correct.[/color]
>
> Mozilla/5.0 including Netscape 6+ implements JavaScript 1.5 and I get
>
> | mocha is not a registered protocol.
>
> `livescript:alert("bla")' does nothing, interestingly.
>
> So I say: It is incorrect. See the point?[/color]

No. Netscape 4, made by the people who created Javascript, used the
words "mocha" and "livescript" about it too. They might not do that
any more, but they did. At some point, Javascript was also known as
Mocha and Livescript (and personally, I would have preferred if they
stayed with "Livescript"). And some people still remember.

I can't see what Mozilla has to do with this.
[color=blue][color=green]
>> When you write
>> <script type="text/javascript">
>> IE interprets the content using its JScript interpreter.[/color]
>
> No, it interprets what is similar to JavaScript with its script
> interpreter. AFAIK that is not a JScript interpreter but one
> that knows also VBScript, part of the Windows Script Host.[/color]

The Windows Scripting Host has several separate interpreters built in.
It can also be extended with, e.g., PerlScript or PythonScript.

The interpreter IE uses for scripts with type="text/javascript" is
the JScript interpreter.
[color=blue][color=green]
>> It is fair to say that JScript is also known as Javascript,
>> so Javascript aka. JScript is correct.[/color]
>
> It is incorrect, JScript is _not_ JavaScript.[/color]

No, but it is *also known as* Javascript. Perhaps incorrectly, but it
is. You would be hard pressed to find people who would claim that
"IE doesn't support Javascript".
[color=blue]
> It is Opera's implementation of ECMAScript, and they falsely call
> it JavaScript.[/color]

Actually, they don't (I should have checked!).
They call it ECMAScript+DOM, and they list their support for non-standard
JavaScript and JScript properties. So that was a lousy argument for me :)
[color=blue]
> Most people call `Internet' now what is in fact the World Wide Web,
> a software application of and for the hardware Internet. People
> call many things by the wrong name because they cannot or refuse to
> understand that this makes a difference.[/color]

Language is a funny beast, and in most countries it is fully
democratic. If enough people decide that something is called
something, then that's what it's called.

While I would love to agree with you, and only use Javascript for the
products of Netscape Corp, even the name of this group shows that that
is now how the word is used. (As a side note, the similar Danish group
is named dk.<something>.clientside, which (while not Danish) is
actually a more fitting name)

When people ask "Javascript" questions, we make sure to give answers
that work in both Opera ECMAScript and JScript too ... because we know
that that is what is meant.
[color=blue]
> ECMAScript is a (programming) language,[/color]

Ok, I was reaching there. It is a programming language.

What the ECMAScript standard says is:
---
This ECMA Standard is based on several originating technologies, the
most well known being JavaScript (Netscape) and JScript
(Microsoft). The language was invented by Brendan Eich at Netscape and
first appeared in that company's Navigator 2.0 browser. It has
appeared in all subsequent browsers from Netscape and in all browsers
from Microsoft starting with Internet Explorer 3.0.
---
(BTW, notice that they call it "The language", as if Javascript and
JScript are the same language.)
[color=blue][color=green]
>> Another is to say that Javascript is ECMAScript (plus som more).
>> And that Javascript Core *is* ECMAScript.[/color]
>
> No, it is not.[/color]

Ok, Javascript Core is an implementation of ECMAScript, extended with
extra features?
[color=blue][color=green][color=darkred]
>>> ECMA does neither watch over JavaScript[/color][/color][/color]

Was the point here that ECMA watches over ECMAScript, not Javascript?
[color=blue][color=green]
>> Obviously you can find the places in the specification that says that
>> what he considers errors, is in fact required by the specification.
>> He thinks the specification should be (or rather: should have been)
>> changed.[/color]
>
> I already know what he "thinks", but I cannot agree with it.[/color]

That's your choice. I agree with some of it.
[color=blue]
> As he tries to impose his opinion on others referring to the
> document, and I was asked to tell what I find wrong about it, I
> answered the question and stated my case.[/color]

You were pointing out that what the standard specified, was different
from what he wanted. There was no need to find the places in the
specification. We know it disagrees.
[color=blue][color=green][color=darkred]
>>> | JavaScript's C-like syntax, including curly braces and the clunky for
>>> | statement, makes it appear to be an ordinary procedural language. This
>>> | is misleading because JavaScript has more in common with functional
>>> | languages like Lisp or Scheme than with C or Java.[/color][/color][/color]

[color=blue][color=green]
>> If Javascript/ECMAScript had tail recursion, you could program
>> functional programs in it.[/color]
>
> And if my grandma had wheels, she would be a motorcycle.[/color]

Just a comment. One thing that I would want changed in ECMAScript.
[color=blue]
> I am pretty sure he has not. What is stated about the execution
> of statements does not fit to a functional language at all.[/color]

No. And?

In *many* ways, Javascript/ECMAScript has *more in common* with
languages like Scheme (first class functions, dynamic typing) and Self
(prototype based object inheritance) than with ordinary procedural
(and even class based OO) languages.

The similarity to Scheme is not as clear as that to Self, but it's
there. If you program Javascript/ECMAScript like you program Java,
you will make lousy programs. The language is different and the
most efficient way to program it is also different ... and has
*more in common* with languages like Scheme and Self.
[color=blue]
> You note the `if'? So if you state that the Guide and Reference is
> not a JavaScript specification, then ECMAScript cannot be a JavaScript
> specification, too, since Netscape's JavaScript as described in the
> Guide and Reference has been always a superset of ECMAScript. So there
> is no JavaScript specification at all.[/color]

Sounds fair.

Ok, from now on, I will use the following notation:

JavaScript (captial S): The JavaScript Core + DOM produced by Netscape
ECMASCript : the language defined in ECMA 262 v3.
Javascript (small s): Any implementation of ECMAScript used in a browser.

The last group of languages needed a name, so I'll use the one that
is commonly used about it.
/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

re: Call a function syntax

"Thomas 'PointedEars' Lahn" <PointedEars@web.de> wrote in message
news:3FC1F795.10601@PointedEars.de...
<snip>[color=blue][color=green][color=darkred]
>>>|The official specification for the language is published by
>>>|ECMA.[/color][/color][/color]
[color=blue][color=green][color=darkred]
>>>Wrong. The official specification for _ECMAScript_ is
>>>published by ECMA.[/color]
>>
>> ECMAScript[/color]
>
>Yes.
>[color=green]
>> aka. Javscript (Core). Yes.[/color]
>
>No.[/color]
<snip>

While it self evidently can be argued that Javascript is distinct from
other ECMA 262 conforming (or near conforming) language implementations
but it seems to be only a pedantic word game to do so. Arguing that
Javascript is unique to Netscape would seem to undermine the strong bias
that comp.lang.javascript has towards cross-browser script development.
The problem with arguing strict literal definitions of a term is that
even if a final decision can be reached about the definitions there is
*always* the opportunity to resume the argument with the definition of
the words used to define the first term. Making any move in that
direction potentially infinitely recurring.

Ultimately, in order to move on, it would have to be accepted that a
nominal term will be understood to mean something sufficiently like what
the person using it intends to the person/people heating it. In the
context of comp.lang.javascript it does not seem unreasonable to use the
term JavaScript to mean something like "a group of programming languages
commonly implemented in web browsers with almost indistinguishable
syntax and behaviour, built around conformance with a version of ECMA
262" even if someone's registered trademark may suggest otherwise. Then
again there may be others who just think "browser scripting language",
but in most contexts that is sufficient to understand its meaning. They
probably don't really need to know, for example, which features
introduced into Netscape's 1.2 version were dropped from version 1.3 in
order to comply with ECMA 262, to understand general comments about a
concept labelled "Javascript".

Richard.