Implicit object constructor misinterpretation

[Lasse Reichstein Nielsen]

That's pretty much points to your regular problem when dealing with
JavaScript, and on a bigger scale - the common problem of many
regulars, getting the base of their wisdom from ECMA262 3rd.ed.
ECMA262 3rd.ed. is an extremely bad source to learn the language
Agree.

because its main purpose is not to explain the language, but to
describe the internal algorithms so make it possible to write
compliant engines for other than Netscape browsers.

No, it's purpose is to *define* the language. Not the internal
algorithms, but the syntax and semantics of it.
The algorithms given in the specification is not something you must
follow, as long as what you do gives the same result.

I must admit that there are places where the format has affected
the specification more than I think is necessary.

In this case, that's not relevant, though, because we are talking
about syntax.

The difference is
as between say a Perl user reference and comments for C libraries used
for Perl processor.
As the result some regulars know some really refined internal
mechanics, some of which even never did into any actual
implementation, yet having troubles to get some obviousnesses. In the
particular and most importantly they are normally having big time
troubles to distinguish *language* features and *underlaying C-based
engine* features and consequently having troubles to separate properly
tokenizing, parsing and execution stages, so applying terms and
entities from one stage to another and vice versa.

I do think you have a point, but your presentation of the point
is marred by you making the same mistake of mixing terminology from
different phases.

One more time, very slow: parsed by the rule of an identifier !== to
be an identifier.

Here you seem to have an idea what it means to be an "identifier".
In Javascript, being an identifier is a tokenization concept. The
thing you seem to think about is called "variable".

In object constructor all key values are string
literals, explicitly or implicitly quoted.

The concept of "string literal" is again a tokenization/parsing
concept. String literals are sequences of characters flanked by either
single or double quotes. They are parsed, and evaluated into string
values.

You cannot quote a string value. Being quoted is a syntactic concept,
which happens even before tokenization.

Again, we are taking about
JavaScript, so about the execution stage. What and how exactly C
program treats the source code stream is irrelevant here yet might be
interesting in other circumstances.

Which is, perhaps, why your explanation isn't being accepted - you uses
parsing/tokenization concepts it.

....

It is the full syntax because in object constructor all key values are
string literals, explicitly or implicitly quoted. Again, we are taking
about JavaScript, so about the execution stage. What and how exactly C
program treats the source code stream is irrelevant here yet might be
interesting in other circumstances.


See right above.

You can't add quotes after tokenization, so if you say that quotes
are added, it must be at the level of tokenization, at the latest.

My guess is that this better matches what you mean:

In object literals, all keys are string values. They can be written
as string literals, or as identifiers or number literals, which is
then converted to string values. Identifiers may not include language
keywords, and numbers are always converted to their canonical string
form, so if, e.g., "default" or "3.0" is used as a key, it must be quoted.

/L

 

[Thomas 'PointedEars' Lahn]

Agree.

IBTD!


PointedEars

 

[VK]

Here you seem to have an idea what it means to be an "identifier".
In Javascript, being an identifier is a tokenization concept. The
thing you seem to think about is called "variable".

No, I think exactly about *identifiers*. Identifiers and variables are
circa in the same relations as human names and human beings
themselves. One person can have several names (Edgar Allan Poe) and
several people can have the same names being distinguished by other
criteria (addresses etc.)
Again:

http://en.wikipedia.org/wiki/Identifier#Identifiers_in_computer_languages
"In computer languages, identifiers are tokens (also called symbols)
which name language entities. Some of the kinds of entities an
identifier might denote include variables, types, labels, subroutines,
and packages."

http://en.wikibooks.org/wiki/C++_Programming/Code/Style_Conventions/Naming_identifiers
"Identifiers are names given to variables, functions, objects, etc. to
refer to them in the program."

The purpose of an identifier is to name something, it is its core
feature and it implies its univalence within the given scope. Other
words identifier foo may identify the most different variables on each
program step (foo=true; foo=bar; foo=null) but it must not identify
two or more different variables at the same time as it ends the
program integrity.
And no, identifiers in JavaScript do not have some special naming-
unrelated function, let's not pretend that JavaScript is from Mars
while all other programming languages are from Jupiter. Higher level
entities may bear different meaning by languages, say "static" method
in C, Java and Visual Basic/VBA mean such different things that they
have nothing in common at all, except the same six letters used to
denote them. But the core entities (algorithm, program, condition,
identifier, subroutine etc.) are the same irrelevant to possible
verbal oopses in this or that document.

The concept of "string literal" is again a tokenization/parsing
concept. String literals are sequences of characters flanked by either
single or double quotes. They are parsed, and evaluated into string
values.
You cannot quote a string value. Being quoted is a syntactic concept,
which happens even before tokenization.

var foo = 'bar';
var obj = {foo : true};
Will it produce obj with property name 'foo' or with property name
'bar'? Is the result caused by parser rules or by language rules
stating that in this particular position it must be a string literal,
either programmer surrounds it by quotes or not?

....

You can't add quotes after tokenization, so if you say that quotes
are added, it must be at the level of tokenization, at the latest.

Disagree with you on that as it implies some mechanicism of the worst
kind in the whole programming (not JavaScript only) with the
programmer being some toy in hands of "pre-programmed elements". If a
programmer types:
var foo = 'bar';
var obj = {foo : true};
he means something at the moment of typing, same way as with the
casual writing. If he means "use the string value 'bar' identified by
foo as the property name in obj" then he simply makes a program
mistake. If he properly means "use string literal 'foo' as property
name in obj" then it is the implicit quoting provided by the language
and used by the programmer: and the implicit quoting happens right
here and then, on typing, not some later out of "good heartiness" of
some C subroutine.
To make it even more clearer let's take Perl where this convenience
typing shortcut was taken from into JavaScript back in 1995:

%obj = (
foo => 'bar',
bar => 'foo'
);

Are we having here foo and bar "identifiers" that become string
literals on the parsing stage? Of course not, these are string
literals written by the programmer using documented shortcuts.

My guess is that this better matches what you mean:

In object literals, all keys are string values. They can be written
as string literals, or as identifiers or number literals, which is
then converted to string values. Identifiers may not include language
keywords, and numbers are always converted to their canonical string
form, so if, e.g., "default" or "3.0" is used as a key, it must be quoted.

Something that cannot be an identifier or number in a given position
cannot be written "as identifiers or number literals". Yes, a
convenience shortcur was taken but the necessary parser logic was not
added to save on parsing time and now it is necessary to deal with it:
but without introducing "non-identifier identifiers", deferred to the
parsing stage programming logic and similar bizzarities.
IM_strong_yet_HO

 

[VK]

IBTD!

It is a unmoderated newsgroup, so don't worry
http://www.urbandictionary.com/define.php?term=ibtd

 

[John G Harris]

On Thu, 29 Oct 2009 at 09:36:40, in comp.lang.javascript, VK wrote:

The purpose of an identifier is to name something,

<snip>

Very true, and in this case it names a property.

However, the language's syntax rules give you three ways to name a
property in an object literal, viz :

as an Identifier
as a StringLiteral
as a NumericLiteral

and it's the job of the parser to cope with all three possibilities and
extract the appropriate property name and deliver it to the next stage
of compilation.

In that next stage you might want to call it an "identifier", but try
not to get confused between the syntax rules that programmers have to
know about and the internal workings of the compiler, which they don't.

John

 

[VK]

  <snip>

Very true, and in this case it names a property.

Well, it was already suggested as a joke in my post at
http://groups.google.com/group/comp.lang.javascript/msg/add1efacca25c5b2
"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".
If you - or anyone else - liked the joke so much that decided to use
it seriously then of course it's your decision: just don't get upset
if others will keep considering it as a joke. Also for the appropriate
transformation of a joke into a serious theory some extra job should
be suggested. In the particular IMHO it is necessary to introduce a
class of "bivalent number literal identifiers" (BiNuLid) that either
used to express numbers or used to identify object property names. In
the last case the identified property name is not directly connected
with the BiNulid's literal form. A few examples of BiNuLids:
300000000000000000003 identifies property name "30000000000000000000"
3000000000000000000003 identifies property name "3e+21"
Overall as I said in the linked post, having enough of beer, spare
time and absolutely nothing better to do, the theory can be brought to
a profoundly perfect dogmatic form (yet remain utterly useless as
such).

However, the language's syntax rules give you three ways to name a
property in an object literal, viz :

 as an Identifier
 as a  StringLiteral
 as a  NumericLiteral

No, the language gives you only one option to name a property in an
object literal, this is a string literal. The language allows you to
be lazy and skip on quotes, but you should be very careful with it
because unlike in other languages with such convenience shortcut,
JavaScript parser doesn't have extra logic added to handle it
properly.

....

 

[John G Harris]

On Sat, 31 Oct 2009 at 10:52:22, in comp.lang.javascript, VK wrote:

No, the language gives you only one option to name a property in an
object literal, this is a string literal. The language allows you to
be lazy and skip on quotes, but you should be very careful with it
because unlike in other languages with such convenience shortcut,
JavaScript parser doesn't have extra logic added to handle it
properly.

The programmer who codes the parser has a function to handle an
Identifier, a function to handle a StringLiteral, and a function to
handle a NumericLiteral all to hand and tested in many releases. But,
you say, he doesn't use them for object literals because he wants to
write the code all over again to do the same job. He ought to be sacked
for doing that.

KEEP IT SIMPLE!

John

 

[Lasse Reichstein Nielsen]

No, the language gives you only one option to name a property in an
object literal, this is a string literal.

No! It is a string *value*!
There are three ways to specify that string value:
Identifier, string literal and number literal.

Please distinguish literals (syntax) from values (semantics)!

/L

 

[VK]

No! It is a string *value*!

http://en.wikipedia.org/wiki/String_literal#Bracketed_delimiters

Why is it important to say "string literal" and not "string value"?
Because this is the point that distinguishes strings here:
var s = 'foobar';
and say here:
var s = 'foo'+'bar';
other words literal and expressions / return values / whatever which
may well be string values.

There are three ways to specify that string value:
 Identifier, string literal and number literal.

Please distinguish literals (syntax) from values (semantics)!

I pretty much understood the point expressed by you and by other
participants. In JavaScript an identifier is whatever is treated on
the parsing stage by identifier parsing rules. Harris' variation:
identifiers that identify string literals resulting from the parsing.
foo identifies property name "foo"
0144 or 0x64 or 100.0 or 100 identify property name "100"
etc.
As I said such "philosophic mechanicism" may be understood after some
efforts, but I am strongly opposing to any attempt to say that this
has anything to do with any common programming terminology or
thinking.

P.S.
var obj = new Object;
obj[0144] = true;
obj[-100] = true;
for (p in obj) {window.alert(p);}
Rather than create some really special programming terms and almost
programming schools just take that the guys were too busy with other
stuff when making JavaScript1.2 so just added implicit constructors
with syntax shortcut atop already rather weird per-property
constructor so the system is as it is but of course without any "non-
identifying identifiers" and stuff.

P.S.S. Yet of course some regulars already might have a set of
definitions for say
obj[-100] = true;
without any "implicit quoting"

But why not just KISS ? Only to be not like everyone?

 

[Lasse Reichstein Nielsen]

http://en.wikipedia.org/wiki/String_literal#Bracketed_delimiters

Why is it important to say "string literal" and not "string value"?

Because they are different and live in different domains. Evaluating
expression syntax creates values. A string literal syntax evaluates
to a string value.

Because this is the point that distinguishes strings here:
var s = 'foobar';
and say here:
var s = 'foo'+'bar';
other words literal and expressions / return values / whatever which
may well be string values.

Indeed. A string literal is a piece of syntax.

In the above 'foobar' is a string literal (eight characters, including
the single quotes), which is also an expression. It evaluates to the
six-character string consisting of the letters f, o, o, b, a and r.

And 'foo' + 'bar' is an expression using the '+' operator on two
sub-expressions that are each string literals. It evaluates, in a
number of steps, to a string value indistinguishable from that of
'foobar'.

The representation of a string value is unknown to the user,
it merely acts as a member of the String type when accessed by the
program.
The representation of a string literal is a sequence of characters
in the program source.


Keys in objects are string values.
In object literals, these string values can be represented by either
string literals, identifiers or number literals.


You keep comming back to unquoted literals and numbers as being merely
shorthands for writing string literals without the quotes.
Thinking of how the language was developed, I don't think that was the
reasoning (without actually knowing it, not being B.Eich).

In JavaScript, objects fills several roles:
- They are object oriented objects, with fields and methods known
to the programmer. These are typically accessed using
identifiers, e.g.:
o.method(o.property), array.substring(array.length - 2)
- They are arrays, indexed by integers, including number literals:
a[42] or a[numbervar]
- They are generic maps from strings to values, indexed using
strings, including string literals:
m["foo"] or m[stringvar]

It makes sense that object literals can be specified in all of these
ways too, even though the underlying object implementation uses
strings for all properties.

var o = { get : function() { return this.x; },
set : function(x) { this.x = x; },
x : undefined };
var a = { 0 : 42, 1 : 13, length: 2 };
var m = {"foo" : o,
"bar" : a };

From the language point of view, they all make their own sense for
differt types of objects, not just as shorthands for map entries.

/L

 

[John G Harris]

On Sun, 1 Nov 2009 at 07:39:30, in comp.lang.javascript, VK wrote:

Harris' variation:
identifiers that identify string literals resulting from the parsing.

<snip>

Not my variation; it's your variation. I suggested you were using
'identifier' as an alias for 'property name', the thing that identifies
a property when the program runs.

Inside the compiler the property name won't be held as a string literal.
If the program is written in C++ then it will most likely be held as a
member of the wstring class; if in C then it will most likely be held in
an array of wchar, ending with a 0x0000 character.

John

 

[VK]

I suggested you were using
'identifier' as an alias for 'property name',
the thing that identifies
a property when the program runs.

Well, this doesn't work because it doesn't have sense in the
programming. I altered it a bit to be if not too useful then at least
sensual:

The identifier foo identifies a variable foo in the context of Global
or function scope. In an implicit object constructor if used in the
position of the property name it identifies string literal "foo" - or
globally: any valid identifier in the position of the property name in
an implicit object constructor identifies string literal consisting of
the character sequence forming the said identifier.

This is an extremely weird approach of course but at least it has some
sense within the human programming science.

Another option - other than claiming your quoted statement be a lore
from the Alpha Centauri programming school - is to stop writing
"identifier" and use "ECMA 262 3rd.ed. Identifier" with the necessary
capitalization and proper reference so then make it clear that you are
not talking about a programming entity but about a charcode sequence
defined by such and such formal criteria. Then:

Any valid ECMA 262 3rd.ed. Identifier in the source code in the
position of the property name in an implicit object constructor is
used as string literal consisting of the character sequence forming
the said Identifier.

This is an extremely weird approach as well but OK, everyone goes to
the hell by his own road


P.S. I see that everyone tried to ignore my little homework so humbly
repeating it

var foo = 'bar';
var obj = new Object;
obj[foo] = true;
obj[-100] = true;
for (p in obj) {window.alert(p);} // "bar", "-100"

1) What is the difference between a Harris' "parsing stage ECMA 262
3rd.ed. Identifier" on and an "identifier" in the casual programming
sense in the program itself.

2) Comment on the second result without using words "to quote" and
"quotes"

 

[John G Harris]

On Sun, 1 Nov 2009 at 12:33:54, in comp.lang.javascript, VK wrote:

The identifier foo identifies a variable foo in the context of Global
or function scope.

In a 'with' statement it identifies a property if the 'with' object has
a property with that name.

In an implicit object constructor if used in the
position of the property name it identifies

...

Another option - other than claiming your quoted statement be a lore
from the Alpha Centauri programming school - is to stop writing
"identifier" and use "ECMA 262 3rd.ed. Identifier" with the necessary
capitalization and proper reference so then make it clear that you are
not talking about a programming entity but about a charcode sequence
defined by such and such formal criteria. Then:

You need glasses. I never *started* using 'identifier' when I meant
'Identifier'.

When did source files stop containing 'programming entities' ?

1) What is the difference between a Harris' "parsing stage ECMA 262
3rd.ed. Identifier" on and an "identifier" in the casual programming
sense in the program itself.

<snip>

We've been trying to work out what you mean when you write identifier.
You seem to change your meaning every other paragraph.

John

 

[VK]

On Sun, 1 Nov 2009 at 12:33:54, in comp.lang.javascript, VK wrote:



In a 'with' statement it identifies a property if the 'with' object has
a property with that name.

Let's not talk about all things at once. Right now we are looking at
an object constructor literal.

 ...

  <snip>

So I understand that besides the suggested definition extension above
the first definition is what you were trying to say. Well, I only can
repeat that "this is an extremely weird approach of course but at
least it has some sense within the human programming science". I still
do not understand why you are considering this approach - not used
anywhere outside this group and actually nowhere outside of this
thread - as something definitely and only right one.

You need glasses. I never *started* using 'identifier' when I meant
'Identifier'.

Possibly not you, sorry then. It was a bounch of exited posts in here
with "identifier", "Identifier" mixed in all different ways.

When did source files stop containing 'programming entities' ?

at the moment it's going through the parser.

  <snip>

We've been trying to work out what you mean when you write identifier.
You seem to change your meaning every other paragraph.

That's rather stupid to claim. All the way though I was very explicit
by what does "identifier" mean in the programming (not in some "VK's
thesaurus" or so): with 3rd source definitions, with samples of
identifiers (not "ECMA 262 3rd.ed. Identifier") on the parsing and
execution stage. You just need to follow the thread.

 

[John G Harris]

Let's not talk about all things at once. Right now we are looking at
an object constructor literal.

But you're the one who is talking about identifiers naming variables. I
just added another case, where it names a property.

All the way though I was very explicit
by what does "identifier" mean in the programming (not in some "VK's
thesaurus" or so): with 3rd source definitions, with samples of
identifiers (not "ECMA 262 3rd.ed. Identifier") on the parsing and
execution stage. You just need to follow the thread.

In all the mainstream languages 'identifier' means any sequence of
characters in a source file that matches the collection of syntax rules
named either 'Identifier' or 'identifier'.

In database technology 'identifier' has a more specific and technical
meaning.

John

 

[VK]

In all the mainstream languages 'identifier' means any sequence of
characters in a source file that matches the collection of syntax rules
named either 'Identifier' or 'identifier'.

It is not a "mainstream" definition of identifiers. It is, as I said
earlier, some aggressive mechanicism with the functional part of the
language abruptly removed. If it is indeed not some of your own
definitions but a CS school definition I am really curious where does/
did it reside. I couldn't find such even in Berserkeley which is
always a place to look for some new weird stuff

 

[John G Harris]

It is not a "mainstream" definition of identifiers. It is, as I said
earlier, some aggressive mechanicism with the functional part of the
language abruptly removed. If it is indeed not some of your own
definitions but a CS school definition I am really curious where does/
did it reside. I couldn't find such even in Berserkeley which is
always a place to look for some new weird stuff

Well, there's Wikipedia, under 'identifier'.

And there's the Pascal report by Jensen and Wirth.

And there's the C++ standard (which you won't have seen because it costs
money). "An identifier is an arbitrarily long sequence of letters and
digits" ...

And there's the O'Reilly book "C# Essentials". "An identifier must be a
whole word" ...

John