Implicit object constructor misinterpretation

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

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.

VK wrote:

Richard Cornford wrote:
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.

"Effective Monday Nov.26 ... all object key strings to be placed in
single quotes with internal single quotes escaped ... [the punishment
stuff is irrelevant]"

OMG.

Now compare this and the full production description with possible
branching from your post. This is exactly what Occam's Raiser is
about, in my humble interpretation of course

The correct spellings for that methodological principle include "Occam's
razor" and "Ockham's razor" (after William of Ockham [1285/8-1348/9 CE],
English philosopher).

For the Fx (ab)normality I am going to ask out of curiosity at
mozilla.dev.tech.js-engine

I pity them already.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7 (AT) news (DOT) demon.co.uk>

Richard Cornford wrote:

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.

"Effective Monday Nov.26 ... all object key strings to be placed in
single quotes with internal single quotes escaped ... [the punishment
stuff is irrelevant]"

Now compare this and the full production description with possible
branching from your post. This is exactly what Occam's Raiser is
about, in my humble interpretation of course

For the Fx (ab)normality I am going to ask out of curiosity at
mozilla.dev.tech.js-engine

VK wrote:

Richard Cornford wrote:
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.

"Effective Monday Nov.26 ...

November the 26th is not a Monday.

all object key strings to be placed in
single quotes with internal single quotes escaped ...
[the punishment stuff is irrelevant]"

Now compare this and the full production description with
possible branching from your post. This is exactly what
Occam's Raiser is about, in my humble interpretation of
course

No, that is arbitrary rules on top of syntax rules. The key/reserved
word rule issue applies to all instances of Identifier use; function,
variable and parameter names, dot notation property accessors, object
literal names, etc. If the person doing the programming understands the
syntax rules then they don't need the addition rules, and if they don't
understand the syntax rules then the additional rules will not render
their output error-free (even with regard to Identifier/reserved word
issues). You are, as usual, attempting to solve the wrong problem.

For the Fx (ab)normality I am going to ask out of curiosity at
mozilla.dev.tech.js-engine

On your record of such promises, I will not be holding my breath.

Richard.

Thomas 'PointedEars' Lahn" wrote:

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"?

Yes I did.

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

Pigs may fly. ;-)

Richard.

VK wrote:

Richard Cornford wrote:
For the Fx (ab)normality I am going to ask out of curiosity at
mozilla.dev.tech.js-engine
Richard Cornford wrote:
On your record of such promises, I will not be holding my breath.

http://groups.google.com/group/mozilla.dev.tech.js-engine/msg/cb7669ddd693937a

VK <schools_ring (AT) yahoo (DOT) com> writes:

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.

If interpreted as a program or statement, yes.
In that context, a "{" starts a statement block.

{
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.

Yes, the "{" starts a statement block, and the content is not a
syntactically valid statement block.

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,

Not really. The "{" is in expression context, so it starts an object
literal. The content is a valid object initializer, so yey, it works.
The "automatic quoting" doesn't really exist. It's a completely
different syntactic construct with different rules, that just happens
to look almost the same.

so we may quote the keys,

We may use string literals as keys. The difference between
foo: 42
and
"foo": 42
isn't that we quote anything, but that one is an identifier and the other
is a string literal. Completely different syntactic categories, both
valid at this particular point of an object initializer.

do not quote them or do quote them zebra-style
or whatever. 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.

It's interpreted as an object key.

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.

No. No quotes are added. The identifier is parsed *as an identifier*.
That identifier is converted to a string value (which takes no
quoting).

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: now no, it is not a constructor but a block of
statements with the second one preceded by an illegal label literal.

Not at all. This is parsed as an object initializer. There is no
automatic quoting, and only string literals and identifiers are valid
keys. Sadly "default" is a keyword, so it is not an identifier, which
makes it a syntax error in the object initializer.

There is no "automatic quoting". There is no "intepretation
decission", only syntactic rules deciding whether a "{" may start
a statement block or an object initializer.

/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

Lasse Reichstein Nielsen wrote:

We may use string literals as keys. The difference between
*foo: 42
and
*"foo": 42
isn't that we quote anything, but that one is an identifier and the other
is a string literal. Completely different syntactic categories, both
valid at this particular point of an object initializer.

I think I am starting to see the mistake making by Richard and by you:
or maybe and very probably not a mistake but some profound difference
in the applied logic between of us, because - I agree in advance - my
logic is too "special".
If unquoted key is interpreted as identifier - in the identifier sense
I am using for more than 10 years and to late to change I'm afraid :
( - then in case like

var a = 'foo';
var obj1 = {a : 'bar'}
var obj2 = {'a': 'bar'}

obj1 and obj2 have to have different properties: 'foo' in the first
case, 'a' in the second. In the reality both of them are having the
same property 'a'

I am really sorry but an "identifier" that is not get identified is
not an identifier, and the whole ECMA 262 wisdom may not override it
in my (stupid, stubborning, whatever) head.

VK <schools_ring (AT) yahoo (DOT) com> writes:

Lasse Reichstein Nielsen wrote:
We may use string literals as keys. The difference between
*foo: 42
and
*"foo": 42
isn't that we quote anything, but that one is an identifier and the other
is a string literal. Completely different syntactic categories, both
valid at this particular point of an object initializer.

I think I am starting to see the mistake making by Richard and by you:
or maybe and very probably not a mistake but some profound difference
in the applied logic between of us, because - I agree in advance - my
logic is too "special".
If unquoted key is interpreted as identifier - in the identifier sense
I am using for more than 10 years and to late to change I'm afraid :
( - then in case like

var a = 'foo';
var obj1 = {a : 'bar'}
var obj2 = {'a': 'bar'}

obj1 and obj2 have to have different properties: 'foo' in the first
case, 'a' in the second. In the reality both of them are having the
same property 'a'

Here you fail to distinguish between an identifier and a variable. In
ECMAScript syntax, an Identifier is a syntactic category. I.e., it
denotes a sequence of characters. It is used in several different
places where something can be given a name: A variable name, an object
property name, a function name. The identifier specifies a name. It
is not the thing it names.

In your example, the identifier "a" is used twice: Once to identify a
variable, and once to identify an object property. The two are not
related. The use as a property name does not refer to the variable,
nor is it evaluated to the variable's value.

Consider this example:
function a() {
var a = {a: 42};
return a.a;
}
The identifier "a" is used five times, three times to name the
function, the variable and the object property, and two times to
reference the variable and the object property.

I am really sorry but an "identifier" that is not get identified is
not an identifier, and the whole ECMA 262 wisdom may not override it
in my (stupid, stubborning, whatever) head.

In the case:

var a = "foo";
function() {
var a = "bar";
}

would you expect the variable inside the function to be called "foo"?
It's called "a" too, because a name *in a declaration* is not interpreted.
It's the same for object initializers: They contain declarations of
properties. The names are not interpreted, so:

var a = "foo";
var b = {a : 42};

declares a property named "a" on an object, not "foo".

/L
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'