From: Thomas 'PointedEars' Lahn on
RobG wrote:

> "Richard Cornford" wrote:
>> Thomas 'PointedEars' Lahn" wrote:
>> > As for the rest, thank you for your patient explanations. One can
>> > only hope something of it gets through to him.
>>
>> Pigs may fly. ;-)
>
> While your wisdom is no doubt lost on VK, it is greatly appreciated by
> others who learn by reading your responses.
>
> If you were to collate your posts to clj for a book along the lines of
> Crockford's Good Parts, I'm sure it would quickly become a best
> seller.

Full ACK. I would like to volunteer for the prufreading the speling ;-)


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.)
From: VK on
Richard Cornford wrote:
> You stated that:-
> "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."

Right.

> "due to some parser quirks they may lead to syntax errors"

Right.

> "do not use the above mentioned syntax shortcut and to use full syntax
> with quotes around each property name"

Right.

> There is no meaning to "quotes are omitted". The names used in object
> literals are one of Identifiers, string literals, or numeric literals.
> String literals are not string literals without quotes and Identifiers
> are not Identifiers with them.

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

> Allowing Identifiers may be for simplicity (or maybe just because it
> seemed like a good idea, or was so obvious that it was never questioned
> and so has no motivation). There is no sense in "omitting" quotes being
> "allowed" for any reason, what is allowed is a choice of tokens.

One more time, very slow: parsed by the rule of an identifier !== to
be an identifier. 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.

> > but if quotes are omitted, some troubles are possible on
> > the parsing stage so better to use them.
>
> The only possible trouble is that if the construct created does not
> conform with the syntax rules it will result in a syntax error.

You call it "the only possible trouble"? It sounds like a joke "the
worst what may happen with you - you may die" :)

> > Simple and clear.

Indeed

> As with much you write, it gets clearer as you edit more out. There is
> no more talk of "syntax shortcut",

It is.

> "full syntax with quotes around each
> property name"

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.

> "the quotes will be added automatically"

See right above.

> "one of reserved
> words in the parser list AND it changes its own previous decision"

Right, and this is one of weak points of the current parser rules. Yet
I understand that the productivity impact to accommodate this problem
may be to serious to be practical.

> "it
> is not a constructor but a block of statements", "consider such code as
> a broken switch-case construction", etc.

Here my interpretation was wrong. "False positive" because of
"default" keyword as the troublemaker. Do not forget that the problem
was obscured by say
var obj = {class: 'foobar'}
being just fine on Gecko, so it took a really unusual combination of
factors to get an object constructor, being to lazy at the moment to
type quotes and thinking that "default" as the last key would be a
good name here.
Yet you may order some champagne to celebrate if you wich :)

> You mean they are processed as Identifiers if they are Identifiers?
>
> > They are not identifiers
>
> Yes they are.

No they are not. See the preface of this post. You need to learn to
distinguish the language and the underlaying engine.

> > and they are not becoming identifiers out of being processed
> > by this rules.
>
> If they were not Identifiers they would not be processed as Identifiers.

.... still long way to go with you... An identifier, an expression, an
object, a function are entities distinguished by their functions and
by their usage in the *language*. Can you make an effort and to get
out from the irrelevant lower level matters? It is JavaScript forum
and we are talking about JavaScript here, not about C or C++ and how
these languages are used to produce a functional JavaScript program
out of the source text.

The rest of post is the same delusion (or a trick?) to talk about
JavaScript running program, source code, C/C++ parser rules at once in
one sentence without any proper attribution of relevant parts to
relevant aspect.


From: Lasse Reichstein Nielsen on
VK <schools_ring(a)yahoo.com> writes:

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

....
>> "full syntax with quotes around each
>> property name"
>
> 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.
>
>> "the quotes will be added automatically"
>
> 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
--
Lasse Reichstein Holst Nielsen
'Javascript frameworks is a disruptive technology'

From: Thomas 'PointedEars' Lahn on
Lasse Reichstein Nielsen wrote:

> VK <schools_ring(a)yahoo.com> writes:
>> 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.

IBTD!


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
From: VK on
VK writes:
> > parsed by the rule of an identifier !== to
> > be an identifier.

Lasse Reichstein Nielsen wrote:
> 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.

VK writes:
> > In object constructor all key values are string
> > literals, explicitly or implicitly quoted.

Lasse Reichstein Nielsen wrote:
> 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