Implicit object constructor misinterpretation

Lasse Reichstein Nielsen wrote:

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.

"VK's universe": identifier "a" is used two times: to name a function
and to name function-level variable. As these entities are in
different scopes we have no identifiers conflict. The third use is
object property name with is implicit string value and not a relevant
part of the test case.
To have an identifiers conflict we obviously need to use them in the
same scope, so to illustrate what was intended to be illustrated we
need to place identifiers in the same scope:
function a() {a=1;} // 1
function a() {a=2;} // 2
window.alert(a.toString()); // the 2dn one
or
a = 1;
a = (a == a + a - a);
window.alert(a); // true

In the case:

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

would you expect the variable inside the function to be called "foo"?

"VK's universe": Of course not because the identified variables are in
different scopes: the outer one (Global if this is the whole code of
the script as posted) with value "foo" and the inner one (function
level).

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

"VK's universe": because object property name is a string one may skip
quotes as they are implied. But in this case it has to conform with
JavaScript naming rules for identifiers because the parser is
optimized for the quickest code source parsing so it will not bother
with each and every non-quoted literal context: it just checks that
each non-quoted literal is either a number, or one of reserved values
like true or null, or a valid JavaScript variable name. If neither it
drops the parsing so do no waste the time.

P.S. I seem to feel what you really tried to say by your samples.
Something like "identifier <a> identifying property name "a" or
something like that and I do agree that such interpretation is
possible - but IMHO such level of abstraction is way too high to be
practical.

"VK's universe": because object property name is a string one may skip
quotes as they are implied. But in this case it has to conform with
JavaScript naming rules for identifiers because the parser is
optimized for the quickest code source parsing so it will not bother
with each and every non-quoted literal context: it just checks that
each non-quoted literal is either a number, or one of reserved values
like true or null, or a valid JavaScript variable name. If neither it
drops the parsing so do no waste the time.

And about the Gecko engine the answer from mozilla.dev.tech.js-engine
just reminded me the old discussion here about the SpiderMonkey's
particular treatment of reserved words: the parser keeps the list not
all reserved words but only ones actually being in use by the current
machine, so for Gecko browsers it is fully OK like:
var class = 'foobar';
window.alert(class); // 'foobar'

VK wrote:

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

I notice that you didn't ask about your fantasy 'automatic quote
insertion', if the interpreter "changes its own previous decision" or
any of that noise you made about the syntax error resulting in the code
being interpreted as "a broken switch-case construction", and/or "a
block of statements with the second one preceded by an illegal label
literal". Probably a good thing as that avoids anyone who actually codes
ECMAScript implementations and reads the propositions suffering fatal
seizures while laughing at you nonsense.

And the (second) answer you got (assuming you are willing to take
Brendan Eich's word as final) is precisely the same as the first one you
got here: ES 3 does not allow keywords as the names in object literals,
but does allow for their acceptance as a syntax extension, and ES 5 will
explicitly allows them. Thus none of the browsers observed are behaving
incorrectly with the example code, and the 'problem' is with the
understanding of the language's syntax possessed by its author.

Richard.

To be the most precise about the weird VK's universe which is can/must
be considered totally twisted yet is immutable by design:

//////////////////////
// explanation starts

Object constructor property names are always treated as string
literals, so quotes around them may be omitted in the source code to
speed up typing and/or for a better code readability. The drawback of
such syntactical shortcut is that then all property names have to obey
the JavaScript naming rules and not be equal to any of JavaScript
reserved words: otherwise due to some parser quirks they may lead to
syntax errors. This way it is highly suggested do not use the above
mentioned syntax shortcut and to use full syntax with quotes around
each property name.

var obj = {
foo : 'bar' // no doughnuts!
}

var obj = {
'foo' : 'bar'// good boy!
}

// explanation ends
//////////////////////

At
http://groups.google.com/group/comp.lang.javascript/msg/715f984ce356c5ae
Richard Cornford shoots the breeze to the full extend of his
definitely remarkable language knowledge and writing skills but he
lost me somewhere at the first third of his post - definitely because
of my IQ level problems. I just managed to get that there are
identifying identifiers like in var a = true; and identifiers that do
not identify anything but still identifiers; I also started to get
that there is some mystical yet deeply profound difference between foo
and foo properties created like this:
var obj = {'foo' : 'bar'}
or like that:
var obj = {foo : 'bar'}
but at this point my on-board computer got overheated and so my mind
disconnected.

I seem to understand - after a few beers - that implicitly quoted foo
in
var obj = {foo : 'bar'}
may be also interpreted as an identifier that doesn't identify
anything. After one more beer I even can imagine that such "non-
identifying identifier" still identifies something: namely string
literal value foo (charcode sequence \u0066\u006F\u006F), in a round
around way like identifier true identifies boolean value true. This
way - after having finished the last beer - I may get ready to
introduce new type of identifiers in JavaScript where each one
identifies a single string literal with charcode sequence equal to
one's of identifier if the latter is taken as a string.
It is possible but I don't see a single reason in syllogistic
exercises of the kind unless trying to occupy one's bored mind: or
unless desperately trying to put some sense into yet another ECMA 262
3rd.ed. verbal fart. IMHO.

P.S. There are two distinct stages for a program: the parsing stage
(with possible syntax errors) and the execution stage (with possible
runtime errors). Respectively there can be different identifiers for
each stage: not those philosophic "non-identifying identifiers" but
normal identifiers for preprocessor variables and identifiers for
program variables. For the moment unfortunately only JScript provides
access to the processing stage, so one needs IE5 or higher to see the
preprocessing results, on other UAs it will be the else-branch. Also
it is a demo code so unnecessarily complicated to involve the needed
instructions:

function demo() {
/*@cc_on
@*/
/*@set @a = 1
@set @b = 2
@if (@_mac)
var obj = {@a : true}
@elif (@_win32)
var obj = {@b : true}
@else @*/
var obj = {3 : true}
/*@end
@*/
for (var p in obj) {
window.
alert('obj[\''+p+'\']='+obj[p]);
}
}

P.P.S. And the "non-identifying identifiers" for property names is
better keep for mind games or best of all throw away. IMHO.

On Sat, 24 Oct 2009 at 10:12:29, in comp.lang.javascript, VK wrote:

<snip>

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.

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

You haven't seen the problem, have you. You can parse this :

var a = { b: 27 };
with (a) b;

because you know for sure what I meant when I wrote it.

With your preferred rule you can't parse this :

var a = { return: 27 };
with (a) return;

because you don't know what I meant when I wrote it.

John

PS This is going to cause trouble in ES 5 non-strict; something else for
Crockford to moan about.
--
John Harris

VK wrote:

To be the most precise about the weird VK's universe which is can/must
be considered totally twisted yet is immutable by design:

Often Wrong, will you *please* spare us your fairytale "explanations" from
your apparently parallel universe? Instead, tell us in *simple* words what
you have understood (please accept the fact that you are yet not capable of
more complex wording in English without posting gibberish). Then you may be
either confirmed or disproved without too much effort.

[...]
I seem to understand - after a few beers - that implicitly quoted foo
in
var obj = {foo : 'bar'}
may be also interpreted as an identifier that doesn't identify
anything.

Will you *please* drop that fantasy of yours? Nothing is implicitly quoted
here! `foo' is called an identifier because it must be produced by the
/Identifier/ production. That production requires that a sequence of
characters conforms to some rules (e.g., it must start with a letter or
underscore), and it must not be a keyword. `default' is a keyword because
it can be produced by the /Keyword/ production.

The part left-hand side of the `:' is supposed to become the name of the
property. If, and only if, the name of the desired property cannot be
produced by the /Identifier/ production (such as with `default'), there are
two possibilities left to make the expression into a syntactically valid
/ObjectLiteral/: It can either be produced by the /StringLiteral/ production
or the /NumericLiteral/ production.

And then, *regardless* of how the name of the property was defined, it is
stored and handled as a string of characters.

Nothing more, nothing less.

After one more beer [...]

Don't drink and derive!


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>

Thomas 'PointedEars' Lahn wrote:

here! *`foo' is called an identifier because it must be produced by the
/Identifier/ production.

Almost perfect, one half in there already! It is no way an identifier,
it is a string *parsed by the rules of an identifier* to speed up the
parsing process, otherwise the parser would need to use a bunch of
positive and negative look-backs to interpret the context properly.
Instead it goes by much more plain but effective way: "no quotes - you
are identifier for now, later the program will decide if it's possible
or not" (plus some icing on the cake with = signs account so do not
make the parser overly stupid).
Now you need to make one last step to recognize that something treated
by rules of another entity doesn't become that entity unless it also
accomplish the functions of the said entity. If the boss treats
someone as a shit it doesn't automatically mean then that someone is a
sh** unless actually acting as a sh**. If someone treats me as a king
I am still not a king unless ruling a kingdom, etc. Wiki definition is
no way normative but is a result of some consensus using authoritative
sources:
http://en.wikipedia.org/wiki/Identifier#Identifiers_in_computer_languages
"In computer languages, identifiers are tokens (also called symbols)
which name language entities."
Unless we are taking my humorous suggestion of foo identifier
identifying \u0066\u006F\u006F (="foo") string literal, unless that it
is of course not an identifier. After some thinking over it you'll
make the last step and will be in here:

//////////////////////
// explanation starts

Object constructor property names are always treated as string
literals, so quotes around them may be omitted in the source code to
speed up typing and/or for a better code readability. The drawback of
such syntactical shortcut is that then all property names have to obey
the JavaScript naming rules and not be equal to any of JavaScript
reserved words: otherwise due to some parser quirks they may lead to
syntax errors. This way it is highly suggested do not use the above
mentioned syntax shortcut and to use full syntax with quotes around
each property name.

var obj = {
foo : 'bar' // no doughnuts!
}

var obj = {
'foo' : 'bar'// good boy!
}

// explanation ends
//////////////////////

VK wrote:

Thomas 'PointedEars' Lahn wrote:
here! `foo' is called an identifier because it must be produced by the
/Identifier/ production.

Almost perfect, one half in there already!

You must be kidding.

It is no way an identifier, it is a string *parsed by the rules of an
identifier*

If by "string" you mean "sequence of characters", then you would be correct.
However, it would be quibbling over words then (your wording would be
precisely my meaning and that of the Specification), because the whole
source code is necessarily a sequence of characters. And quibbling over
words does not become someone like you who posts gibberish regularly.

[more VK nonsense]

I do not know what point you were trying to make there, but, as usual, you
failed badly in doing that.


PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)

Thomas 'PointedEars' Lahn wrote:

`foo' is called an identifier because it must be produced by the
/Identifier/ production.

VK wrote:

Almost perfect, one half in there already!

Thomas 'PointedEars' Lahn wrote:

You must be kidding.

Deadly serious. You just keep thinking over it - the main part of the
path is already done. btw somehow I overlooked the answer of Brendan
Eich to my post at mozilla.dev.tech.js-engine Who doesn't have this
group and doesn't want to use GG I am copying it here:

VK wrote:

Having a statement such as:

var obj = {
foo: 'bar',
default: 'default_value'
}

Firefox 3.5.3 creates obj with properties foo and default.

IE reports syntax error "Expected identifier, string or number", same
or similar syntax error occurs on Safari, Chrome and Opera. By placing
default into quotes we are making the code valid for all browsers in
question:

var obj = {
foo: 'bar',
'default': 'default_value'
}

My question is if it is a Gecko bug, a convenience extension or the
proper implementation by ECMA with others being wrong on that?

Brendan Eich wrote:
Not a bug, yes a convenience, and proper implementation of ES5 (after
ES3.1 and ES4, which both allowed reserved words to be used in
property-name contexts). Also a proper extension to ES3, which allows
such syntactic extensions (see chapter 16).

IE has yet to ship the ES5 JScript implementation I've seen demo'ed at
Ecma TC39 meetings.

So it is as as earlier explained: property names are strings,
explicitly quoted or implicitly quoted. Brendan Eich refers to ECMA
262 3rd.ed. Chapter 16 "Errors"
http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf
and logically I do agree with him: if a non-quoted character sequence
in this position is guaranteed to be quoted (treated as a string
literal on the execution stage) then it is really not a parser's
monkey business to check its language naming conformance or check it
against a reserved words table.
Any way coming back to the same:

//////////////////////
// explanation starts

Object constructor property names are always treated as string
literals, so quotes around them may be omitted in the source code to
speed up typing and/or for a better code readability. The drawback of
such syntactical shortcut is that then all property names have to obey
the JavaScript naming rules and not be equal to any of JavaScript
reserved words: otherwise due to some parser quirks they may lead to
syntax errors. This way it is highly suggested do not use the above
mentioned syntax shortcut and to use full syntax with quotes around
each property name.

var obj = {
foo : 'bar' // no doughnuts!
}

var obj = {
'foo' : 'bar'// good boy!
}

// explanation ends
//////////////////////

VK wrote:

Thomas 'PointedEars' Lahn wrote:
`foo' is called an identifier because it must be produced by the
/Identifier/ production.

VK wrote:

When will you ever learn?

Almost perfect, one half in there already!

Thomas 'PointedEars' Lahn wrote:
You must be kidding.

Deadly serious. You just keep thinking over it - the main part of the
path is already done. [...]

Idiot.


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