From: Thomas 'PointedEars' Lahn on
VK wrote:

> John G Harris wrote:
>> The man who invented the language said it must be like that. Get used to
>> it.
>>
>> If you can't, find another language.
>
> I wouldn't put the strict equality sign between what the Man did and
> what others (ECMA freelancers) managed to write about it.

Brendan Eich is at least in the contributor's list for all three Editions of
the ECMAScript Language Specification, and its apparently upcoming fifth
Edition. You make it look instead as if the ECMAScript standardization
process had/has nothing to do with him. That is extremely unfair of you
given his ongoing efforts to improve the language, and quite presumptuous
given that you are using it to justify your ongoing fantasies about how
things would be. Go away.


PointeddEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
From: VK on
Gregor Kofler wrote:
> For the less perceptive (like you): "default" is a reserved word in JS.

The same pre-requisite asked to distinguish between literals and
string values. Se also
http://groups.google.com/group/comp.lang.javascript/msg/3a0cb6ffc451e69b

From: Thomas 'PointedEars' Lahn on
VK wrote:

> Thomas 'PointedEars' Lahn really killed me recently after years of
> quoting to death different papers and then not knowing that delete
> this.val is not allowed at least in IE.

Stop perverting the facts. It is apparently not allowed if `this' refers to
the ECMAScript Global object *only* in JScript so far -- a clear *bug* (that
no reasonable implementation is going to produce). In all other cases proof
that it does not work has yet to be given.

> For me it's like if someone knows by heart all von Clausewitz and all
> field regulations yet not able to reload his own rifle :)

Obviously it did not cross your puny malfunctioning replacement of a mind
that I never needed to delete any properties of the ECMAScript Global Object
in the first place (guess why).


PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
From: Richard Cornford on
VK wrote:
> John G Harris wrote:
>> The man who invented the language said it must be like that.
>> Get used to it.
>>
>> If you can't, find another language.
>
> I wouldn't put the strict equality sign between what the Man did
> and what others (ECMA freelancers) managed to write about it.

Why not? Brendan Eich invented that language and Brendan Eich sat on the
committee(s) that wrote the spec(s). If the committee members had any
questions bout intentions they also had direct access to the answers to
those questions.

> Say it was
> obvious for the Man that in case
> (function f() {
> })()
> function f being created and added to the namespace. It was so for
> him, for NN2.x-4.x,

Netscape 4 was an ECMA 262 2nd Ed. implementation, that version of
ECMAScript does not include function expressions at all. So in that
environment they were a syntax extension, and probably an experimental
one at that.

> for Eric Lipper porting it to IE.

No he didn't. at least that is not what JScript does, or ever has done.
In JScript the construct:-

(function f() {
})();

- results in the creation of two function objects. The first during
variable insanitation as the execution context is entered, which is then
assigned as a property named 'f' on the applicable Variable object. The
second during the evaluation of the expression, where that second
function object gets called. If code in either of the two functions
attempted to use the Identifier - f - to call a function then it would
be he first of these two function that would be the one called.

This behaviour in JScript is sufficiently irrational that there is
virtually zero chance that it exists by design (i.e. it is a bug, even
without considering what any ECMA standard may say on the subject), and
it certainly will not represent a (sucessful) porting of anything that
was done in pre-existing Netscape browsers.

> Only much later during the "hand-pointer" opposition stage
> some read out an alternative meaning from ECMA to make IE
> wrong in yet another small but pleasurable point.

JScript did not claim to be a ECAM 262 3rd Ed implementation (the first
version of the standard to include function expressions) before version
5.5, so while it did not make the claim it could not be faulted for not
satisfying the claim. As soon as the claim to be a conforming
implementation is made any failure to conform is a bug by language
specification.

> On the topic and if you manage to fight over the regular
> "get VK!" instincts than you see that:
>
> {
> a: "a",
> b: "b"
> }
> is interpreted as a block with a and b label literals.

No, that is interpreted as a syntax error. Labelled statements, being
statements, cannot appear on the right hand side of a comma operator
(only an Expression may appear in that context). Changing the comma to a
semi-colon, or just removing the comma while retaining the line
terminator, removes the syntax error, but both actions preclude even the
possibility that the construct be used in an object literal context a
then it becomes a different syntax error.

> {
> a: "a",
> "b": "b"
> }
> is interpreted as a block with a and b label literals where b
> is illegal as we cannot use string value instead of literal so
> syntax error.

Which might be more meaningful if you first example had not also been a
syntax error.

> var obj = {
> a: "a",
> "b": "b"
> }
> creates the necessary interpretation context so the right part is
> treated as an object constructor and the automatic quoting gets
> on, so we may quote the keys, do not quote them or do quote them
> zebra-style or whatever.

Haven't I already pointed out what a nonsense this proposal that some
sort of 'automatic quote insertion' happens during tokenising/parsing
is? I suppose that just went straight over your head again. If that
could happen then all sorts of possibilities would come into play.

Rather the situation is relatively simple. The evaluation of an object
literal results in the creation of a new object and for each name/value
pair in the literal a new named property is added to that object where
the rules for determining the character sequence in that name are:- if
the name part is an Identifier then the character sequence from the
Identifier is used as the new property's name, if the name part is a
string literal then the character sequined from the string literal is
used as new property's name, and if the name part is a numeric literal
that is evaluated to produce the number value and that numeric value is
type-converted into a string, and then that character sequence form that
string is used as the new property's name.

There is no need to propose any automatic insertion of quotes into the
source text (or token stream) in order to account for the behaviour
seen. And indeed such insertions would be contrary to the behaviour
observed. For example:-

var x = {
x-y:5
};

- is a syntax error but:-

var x = {
'x-y':5
};

- is not. The first being a mathematical expression in a context that
only allows for Identifiers, string literals and numeric literals, while
the second is a numeric literal. There is no reason for any 'automatic
quote insertion' not to accommodate the former.

var x = {
x:1,y:2
};

- is a valid object literal, and so is:-

var x = {
'x:1,y':2
};

Similarly:-

var x = {
':::::':0
};

- is a valid object literal, but:-

var x = {
::::::0
};

- never could be, except that, if they existed, it could be rendered
valid by some sort of 'automatic quote insertion' rules.

var x = {
'@@@@@':0
};

- is fine, but you won't get awya with:-

var x = {
@@@@@:0
};

> Even if the very first key is not quoted, it is still
> interpreted as key string value, because the "interpretation
> decision" is being made before that.

Only in the sense that the behaviour resulting form the use of an
identifier in the name part of an object literal is already well
defined.

> var obj = {
> a: "a",
> "default": "b"
> }
> absolutely the same as before, the "interpretation decision"
> is being made before entering so it is already decided that
> it is an object constructor and not a block of statements, so
> it is irrelevant that the first key is not quoted: the quotes
> will be added automatically.
>
> var obj = {
> a: "a",
> default: "b"
> }
> the "interpretation decision" is being made before entering so
> it is already decided that it is an object constructor and not
> a block of statements, so it is irrelevant that the first key
> is not quoted: the quotes will be added automatically;
> THEN the system meets [default] chars sequence which corresponds
> to one of reserved words in the parser list AND it changes its own
> previous decision:

You see, your over-elaborate fantasy of 'automatic quote insertion'
needs a whole list of special cases to account for what javascript
actually does. You have problems accounting for any used of key/reserved
words, for expressions, for unexpected character sequences. So on top of
what you have you also need a massive array of additional rules.

The alternative of, if it is an Identifier, a string literal or a
numeric literal it will be predictably handled, and if it is not then a
syntax error should be expected, covers the situation nicely. And if
some implantations want to extend either the definition of Identity, or
the named part of an object literal, to include reserved words then that
does not introduce much additional complexity.

I find it humorous that your profile in Google groups quotes Ockham's
Raiser in Latin, as I cannot think of any better demonstration of
spectacularly missing the point. Here we have a case where the simpler
explanation certainly is the better explanation.

> now no, it is not a constructor but a block of
> statements with the second one preceded by an illegal
> label literal.

No it isn't. It is just an object literal that contains a syntax error.

Earlier today you were asserting that including the 'default' in an
object literal was resulting in its interpretation as a "a broken
switch-case construction", and I asked you what evidence you had for
that assertion. You never were going to provide any such evidence as you
never had any. Instead you had just made that assertion up off the top
of your head. Here again you are making this up off the top of your
head. For a start, the interpreter is very unlikely to ever switch to
attempting to interpret this as a Block statement for the simple reason
that no Statement is allowed to be the right hand side of an assignment
operation. By the time the parser has seen the assignment operator (the
single = sign) we are in an Expression context, and the only question is
whether what follows is a syntactically correct Expression or not.

> Some might find it very logical. I am definitely not in
> that club.

If even you do not find your own fantasies logical why do you bother
anyone else with them?

Richard.

From: Thomas 'PointedEars' Lahn on
Richard Cornford wrote:

> There is no need to propose any automatic insertion of quotes into the
> source text (or token stream) in order to account for the behaviour
> seen. And indeed such insertions would be contrary to the behaviour
> observed. For example:-
>
> var x = {
> x-y:5
> };
>
> - is a syntax error but:-
>
> var x = {
> 'x-y':5
> };
>
> - is not. The first being a mathematical expression in a context that
> only allows for Identifiers, string literals and numeric literals, while
> the second is a numeric literal.
^^^^^^^
Do you mean "string"?

As for the rest, thank you for your patient explanations. One can only hope
something of it gets through to him.


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann