ECMAScript Version 4

[Simula]

Hello All,

Does anyone have any knowledge of when version 4 will be released? I
think that version 3 was finalized in 1999 and it would be really nice
to have the class keyword and statically typed variables.

Thanks,
Mark

 

[Richard Cornford]

Does anyone have any knowledge of when version 4 will be
released? I think that version 3 was finalized in 1999

Edition 4 is now every overdue, in the sense that it was supposed to be
released some time ago. It now seems unlikely that it will ever be
finalised, because Microsoft have already released their version as
JScript.net and are now not motivated to agree a standard that has moved
on, while everyone else don't seem keen to roll back to the version
Microsoft implements (and yes that is 100% speculation).

Not that the release of edition 4 would change anything for many years
as we are still at a point where the wisdom of using some language
features introduced in edition 3 is debatable.

There is also a great deal to be said for never having another version
of ECMAScript. As it is everyone is in a position to move towards one
consistent standard, and as the few bugs in current implementations get
fixed we are very close to having a genuinely reliable bases for the use
of the language. A new language version would call for in half a dozen
new implementations and a whole new set of bugs, differing between
implementations.

and it would be really nice to have the class keyword

I see no advantage in that. Every useful concept form class-based
languages are demonstrably implementable in ECMAScript.

and statically typed variables.

Many of the most useful techniques for accommodating differences between
browser object models are facilitated by ECMAScript's loose typing. And
loose typing forces programmers to adopt a more disciplined approach to
perceiving the types they are using, because the language does not make
them obvious.

If you want to program Java or C++ why don't you do that? As it is
ECMAScript is the ideal language for scripting web browsers because it
is dynamic and flexible enough to efficiently accommodate a wide range
of execution environments. Making it more like Java would not help in
that respect at all, as Java is specifically designed for, and lends
itself to, one single and precisely defined execution environment.

Richard.

 

[Stephen Chalmers]

Hello All,

it would be really nice to have the class keyword and statically typed variables.

In a compiled language no doubt, but the introduction of a standard will not magically update the range of interpreters
currently in use; making it impractical to exploit such features in code intended for public consumption.

 

[Simula]

Richard,

As you have pointed out, Javascript is very close to Java or C++ as it
is. Javascript already has classes, it is just that all variables are
public and the function keyword is used to define them. Classes are
for grouping your variables and functions into clear categories and I
think that the class keyword would help clarify the endeavor.

I'm not saying that I wish that the current methods for defining
classes are done away with, just that clearer and more widely known
techniques are added.
I assert the same thing for static typing. I would not wish that
dynamic typing be removed, but static typing would help developers
stamp out logical errors and would potentially result in a speed
increase (if implemented).

I do agree that it would take quite a long time for version 4 to be
implemented within browsers, but I think the additions are worthwhile.
My thought is that the sooner the standard comes out, the sooner it can
be implemented (even if we are talking another 5+ years).

Thanks for the speculation Richard, it helps me understand the
landscape.
Mark

 

[Michael Winter]

As you have pointed out, Javascript is very close to Java or C++ as it
is.

I don't think Richard did anything of the sort. ECMAScript shares syntax
with other languages (not just C++ and Java), and many of the reserved
words from Java, but the similarities more-or-less end there.

Javascript already has classes,

No, it doesn't.

it is just that all variables are public

If you create public members, then clearly they will be public. But, as
Richard did point out, ECMAScript is capable of more: both public and
private, static and instance members are feasible. Protected members are
also possible, but they require a lot more effort.

and the function keyword is used to define them.

The function keyword defines functions. This does include constructor
functions, but these are still just functions, not classes. The only
special thing about them is that they are written with object
construction in mind - you could still call a constructor function like
any other function.

Classes are for grouping your variables and functions into clear categories

Classes define objects, which in turn allow for abstraction and provide
a way in which a problem can be broken down. Encapsulation groups data
and behaviour.

and I think that the class keyword would help clarify the endeavor.

I would disagree, in that well-written code will have established
conventions that would make something like a constructor function easily
identifiable. Thorough documentation will also aid understanding of the
code.

I'm not saying that I wish that the current methods for defining
classes are done away with, just that clearer and more widely known
techniques are added.

And you're willing to wait around several years for that?

I assert the same thing for static typing. I would not wish that
dynamic typing be removed,

Unless some nasty variant type is added, you can't have both. I would
expect such a type to be horribly misused by many who don't want the
hassle of actually managing their code properly. I've seen VB code where
*everything* is a Variant. Not an Integer or String in sight!

but static typing would help developers stamp out logical errors

Far from it. Logic errors occur in any sort of code. Static typing just
prevents the change of type at run-time. Only proper testing can prevent
non-syntactic errors.

and would potentially result in a speed increase (if implemented).

Maybe, but the potential loss of the dynamic properties of ECMAScript
isn't worth that.

I do agree that it would take quite a long time for version 4 to be
implemented within browsers, but I think the additions are worthwhile.

It's not how long it would take to be implemented, but how long it would
take for older implementations to fade away. Using the class keyword,
for example, in any current implementations will elicit a syntax error
because class is a future reserved word. Unless a versioning system is
reintroduced, or perhaps a MIME type is registered that existing
implementations won't recognise, you'd have to keep using the same
features from the Third Edition.

[snip]

Mike

 

[cwdjrxyz]

Hello All,

Does anyone have any knowledge of when version 4 will be released? I
think that version 3 was finalized in 1999 and it would be really nice
to have the class keyword and statically typed variables.

Thanks,
Mark

There is a page at http://www.mozilla.org/js/language/ that might be of
interest. It has links to older versions and some links to preliminary
versions of 4. The page is not new, but things seem to be moving at a
snail's pace over the last two years.

If you want to see some really drastic changes and extensions in code,
just look at the code that the W3C is working on to replace xhtml 1.1.
The change, so far as the code writing goes, was not drastic from the
1.0 strict to the 1.1 version. However 1.1 does not have frameset and
transitional versions. I have not yet checked to see what the new xhtml
might mean for javascript, if anything.

 

[Richard Cornford]

Richard,

As you have pointed out, Javascript is very close
to Java or C++ as it is.

I did not point that out, as it is not true.

Javascript already has classes,

There are not really classes in ECMAScript. All ECMAScript objects are
of the same type, they are just sometimes augmented to have different
properties. This allows them to be perceived as of different types, and
so numerous objects to be of the same distinct 'type', but in reality
they differ only in terms of what has been done to them, and resemble
each other in having had similar things done to them.
The constructor functions are actually a mechanism for arranging to have
numerous objects augmented in similar ways, but not the only means of
doing so by a long way.

Because you can have objects that are all essentially the same (totally
dynamic) type act as instances of the same 'type' and differ from other
'types', allows concepts of classes and instances of classes to be
employed in ECMAScript, even to the extent of designing and describing
code with UML. But it is just a way of thinking about that code, that
may be useful for some applications, and superfluous or inappropriate in
others.

it is just that all variables are public and the function
keyword is used to define them. Classes are for grouping your
variables and functions into clear categories and I
think that the class keyword would help clarify the endeavor.

It is not difficult to see the grouping of constructor function and
prototype definition as a distinct unit (as common sense would have them
physically adjacent in source code), but if you want more explicit
grouping then you can do that yourself easily enough. Being able to
stick the label 'class' in the source code wouldn't make that much
difference, and the common naming convention of giving constructor
functions initial upper case names should tip readers off when the
concept of 'class' is being implemented, and which code is involved.

I'm not saying that I wish that the current methods for
defining classes are done away with, just that clearer
and more widely known techniques are added.

The problem with continuing to provide the existing mechanisms and then
loading class definitions on top is that it will make the language
considerably more complicated to learn for no significant benefits. Even
those familiar with class-=based languages will need to put work into
understanding how the proposed ECMAScript version differs from their
expectations (in the same way a C++ programmer would have to put effort
into learning how Java differed from their expectations) and because the
original mechanisms remain the novice also has to learn those, in order
to appreciate the circumstances under which they would better suite the
application of the language.

Except, of course, programmers with class-based language experience
would stick to what seemed familiar to them and never go into the areas
of the language that they did not recognise. Javascript already suffers
from that, with many individuals authoring it without any interest in
fully understanding it, and writing code that falls very short of what
it could be as a result.

I assert the same thing for static typing. I would not wish
that dynamic typing be removed, but static typing would help
developers stamp out logical errors and would potentially
result in a speed increase (if implemented).

And I make the same response for typing. If you retain loose typing
along side strict typing you end up with something that is more
complicated. All of the type safety that strict typing is supposed to
impose is undermined by the loose typing along side it, and the
programmer's discipline of having to always keep track of types
themselves is also relaxed. The result is more likely to be the worst of
both worlds than the best of both.

I do agree that it would take quite a long time for version
4 to be implemented within browsers, but I think the additions
are worthwhile. My thought is that the sooner the standard
comes out, the sooner it can be implemented (even if we are
talking another 5+ years).

<snip>

As I have said, I don't see any benefits in the proposed changes. What I
do see is a (long) transition period where browser script engines are
destabilised just at the point when they are starting to settle down
into being something consistent. Even where apparent back-compatibility
with ECMA 262 3rd edition was achieved by a new 4th edition script
engine the mere fact that it must be a new script engine will mean the
introduction of new bugs, in both its back-compatibility and its new
capabilities. And every other browser would have a different new script
engine with its own bugs.

It seems reasonable that there should be a range of languages for
differing task, and languages better suited to those tasks. ECMAScript,
as it is, is very well suited to scripting web browsers (and other
object models), it is less well suited to being used to write the
business logic for an enterprise, and it would be insanity to attempt to
write an aeroplane fly-by-wire system with it. We have class-based
languages, and employment for them. ECMAScript does not need to be yet
another, inferior, cousin to one of them when it is currently something
valuable in its own right.

Richard.

 

[Dr John Stockton]

JRS: In article <[email protected]>
, dated Mon, 27 Jun 2005 18:30:12, seen in

Does anyone have any knowledge of when version 4 will be released? I
think that version 3 was finalized in 1999 and it would be really nice
to have the class keyword and statically typed variables.

One would only be able to use them in safety on an Intranet; it would
take several years before innovations would be safe on the general
Internet/Web.

ISTM that it might be better to have a new language, that being defined
by having a new name. It could include much of the latest javascript,
but would not need to support quaint features such as getYear and months
being 0..11. It could support applicable international standards by
default, with localisation for non-compliant regions.

It would seem wise to state that the first version should only be used
on Intranets (without preventing wider use); the subsequent for-general-
use versions would then have had a design-and-implementation debugging
stage before reaching the wiser public.

 

[Thomas 'PointedEars' Lahn]

it would be really nice to have the class keyword and statically
typed variables.

In a compiled language no doubt, [...]

Please do note that J(ava)Script/ECMAScript (following: JS) are compiled
languages and they are interpreted ones. They are source code compiled
into bytecode that is interpreted by a Virtual Machine afterwards, much
like it is with Java. The only difference is that compilation with JS
in almost all cases is performed at runtime (just-in-time compilation).


PointedEars

 

[Lasse Reichstein Nielsen]

Please do note that J(ava)Script/ECMAScript (following: JS) are compiled
languages and they are interpreted ones.

The only meaningful way to distinguish what I would call compiled and
what I would call interpreted languages, is that compiled languages
are compiled only once, whereas interpreted languages start from the
source code each time they are run.

Any language can be compiled to something else, and any language can
be interpreted by a suitable interpreter, so it's not really the
language that decides, as much as the common use of it. Then again,
some languages are more obviously build for interpretation than
others.

I'd say that JavaScript was designed for interpretation rather than
compilation. This is suggested by a lot of small properties rather
than one specific thing. It's things like the availability of "eval",
allowing handling of source code at run time, and the lack of, e.g.,
types, which are practical when you can check them statically at
compile-time.

So, I'd call JavaScript, and ECMAScript, interpreted languages,
not compiled ones, because they are typically run from source
every time, and are designed to be so.

/L

 

[Thomas 'PointedEars' Lahn]

The only meaningful way to distinguish what I would call compiled and
what I would call interpreted languages, is that compiled languages
are compiled only once, whereas interpreted languages start from the
source code each time they are run.

That is the flaw in your argumentation. You distinguish between begin and
end of the process where you should distinguish between input/output pairs.
There are languages, if seen as a whole, that are not either compiled or
interpreted but both (first) compiled and (then) interpreted, as it is e.g.
with JS, and with Perl (ref. `man 1 perlcompile').

[...]
I'd say that JavaScript was designed for interpretation rather than
compilation.

Apparently you did not understand what I wrote. JavaScript[tm] was
*designed* as a language specifying human-readable source code to be
compiled into bytecode and then have this bytecode interpreted by a
Virtual Machine in the first place (which makes it cross-platform).
It was not specified as source code that has to be JIT-compiled,
although that was a reasonable approach if used in an HTML UA
environment for which it was, undeniably, originally designed:

<http://wp.netscape.com/comprod/columns/techvision/innovators_be.html>

Strictly speaking, JavaScript is a language to be compiled into JavaScript
bytecode, and JavaScript bytecode is a language to be interpreted by a VM
(according to the platform it is run on). This, however, does not make
JavaScript an interpreted language; strictly speaking, it makes JavaScript
rather a compiled language because JavaScript bytecode would then be a
different language.

If JavaScript was only an interpreted language (e.g. like bash), source
code would be executed line by line and only if a line was reached it
would be checked for syntax errors prior to execution. However, JavaScript
syntax errors are recognized before the script is run. The reason is that
a compiler checks the source code for correctness, compiles it into
bytecode if it is syntactically correct and then the resulting byte code
is interpreted, i.e. executed, by the JavaScript VM (which may result in
runtime errors). The compound that makes up a at least the JavaScript
JIT-compiler and the JSVM is called the JavaScript engine:

[...]
So, I'd call JavaScript, and ECMAScript, interpreted languages,
not compiled ones, because they are typically run from source
every time, and are designed to be so.

No, they certainly are not! While this is a common misconception, neither
the Netscape JavaScript Reference nor the ECMAScript Specification state
anything of the kind. Especially, ECMAScript Ed. 3 contains the following
paragraphs:

| 7.6 Identifiers
| [...]
| Two identifiers that are canonically equivalent according to the Unicode
| standard are not equal unless they are represented by the exact same
| sequence of code points (in other words, conforming ECMAScript
| implementations are only required to do bitwise comparison on
| identifiers). The intent is that the incoming source text has been
| converted to normalised form C before it reaches the compiler.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

| 15.10.2.2 Pattern
| [...]
| Informative comments: A Pattern evaluates ("compiles") to an internal
^^^^^^^^^^^^^^^^^^^^^^
| function value. RegExp.prototype.exec can then apply this function to a
| string and an offset within the string to determine whether the pattern
| would match starting at exactly that offset within the string, and, if it
| does match, what the values of the capturing parentheses would be. The
| algorithms in section 15.10.2 are designed so that compiling a
^^^^^^^^^^^
| pattern may throw a SyntaxError exception; on the other hand, once the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| pattern is successfully compiled, applying its result function to find a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| match in a string cannot throw an exception (except for any host-defined
| exceptions that can occur anywhere such as out-of-memory).

While the former may be debatable as a proof because "to compile" can have
different meanings (including, but not limited to: to construct, to build,
to contain, to compose), the relation between compilation and syntax errors
is made quite visible here, so ISTM that the process a source code compiler
(more exact: the source code parser which part of the compiler) performs is
referred to here as well.

Furthermore:

| 16 Errors
|
| An implementation shall not report other kinds of runtime errors early
| even if the compiler can prove that a construct cannot execute without
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| error under any circumstances. An implementation may issue an early
| warning in such a case, but it should not report the error until the
| relevant construct is actually executed.

<http://www.mozilla.org/js/>


HTH

PointedEars

 

[Lasse Reichstein Nielsen]

Lasse Reichstein Nielsen wrote:

That is the flaw in your argumentation. You distinguish between begin and
end of the process where you should distinguish between input/output pairs.
There are languages, if seen as a whole, that are not either compiled or
interpreted but both (first) compiled and (then) interpreted, as it is e.g.
with JS, and with Perl (ref. `man 1 perlcompile').

As you later point out, that would be a compiler for Perl and an
interpreter for Perl parse trees. I say it's just Perl having
a parser for Perl available that is also the same parser being
used by the Perl interpreter.


But that is beside my point. There are many ways to run a program.
You can either make an interpreter to run it, or you can make a
compiler to another language, and then use an interpreter for that
language (the second language can be machine code with a CPU doing
the interpretation).

Also, there are many ways to make an interpreter for a language (which
is what I call something that takes a program in that language as
input and then runs it). All interpreters of source code (text based)
programs will parse the source and have some internal representation.
That internal representation can be simple data structures, parse
trees (like Perl) or some kind of byte code. You might even call the
parser a "compiler", but that does not change that it is just a part
of an interpreter: something taking a program as input and running it.

For a language to be compiled, I require that the result of the
compilation can be meaningfully stored and later run as a program of
its own. If it can't, then the "compiled program" is simply an
intermediate result of the interpreter (or whatever program it is part
of).

A compiler transforms a program in one language into another form,
which is probably another language. That other form can be native
code, byte code (e.g. Java or OCAML) or some other language source
code (e.g., assembler as from "gcc -S" or the language itself as from
"gcc -E"). If can store this other program, and run it later, several
times, without having to recreate it from the source code each time.


Looking at input/ouput pairs (if I correctly understand what you mean
by that), an interpreter takes a program is input and gives no output
(except what the program itself might do of I/O). A compiler takes a
program as input and gives another program as output, in another
language or format. If we ignore what happens inside, that's the I/O
characteristics of an interpreter and a compiler. More importantly, a
compiler doesn't run the program it processes, an interpreter does.

Actually, it always requires an interpreter to *run* a program.
Through compilation, you can get to the point where that interpreter
is in the CPU, or you can stop earlier and have your own interpreter
(which is run by the CPU).

[...]
I'd say that JavaScript was designed for interpretation rather than
compilation.

Apparently you did not understand what I wrote. JavaScript[tm] was
*designed* as a language specifying human-readable source code to be
compiled into bytecode and then have this bytecode interpreted by a
Virtual Machine in the first place (which makes it cross-platform).

Where do you find this (that JavaScript was designed for being
parsed into bytecode)?

It is designed for ease of writing and being cross-platform, I can
agree on as much, but whether the actual implementation of it shoud
use bytecode or not is not something I can read from the link you
give, nor from the ECMAScript standard.

It was not specified as source code that has to be JIT-compiled,
although that was a reasonable approach if used in an HTML UA
environment for which it was, undeniably, originally designed:

What is clear, is that the primary format of exchange of Javascript
code is source code, and that every web page containing Javascript (as
you say, the orignal design target of JavaScript) will start from
source code every time it is read. While there might be internal
compilation in the interpreter, it is hast the I/O characteristics of
an interpreter.

<http://wp.netscape.com/comprod/columns/techvision/innovators_be.html>

Strictly speaking, JavaScript is a language to be compiled into JavaScript
bytecode, and JavaScript bytecode is a language to be interpreted by a VM
(according to the platform it is run on).

What is this "JavaScript bytecode" language? Is it standardised
anywhere? Or maybe it is just an artifact of the implementation of
one interpreter.

I know that Rhino uses an internal JavaScript bytecode, and so does
SpiderMonkey. I don't know if it's the same format, though. I'm pretty
sure that other ECMAScript implementations, even if they use bytecode
internally, doesn't use the same bytecode (e.g., JavaScriptCore, KJS,
Opera's ECMAScript, JScript). I'm certain that JScript 2.0 is compiled
into CLI, not JavaScript bytecode (as used by Rhino and/or
SpiderMonkey). Resin even has a compiler from Javascript to Java
bytecode, yet another bytecode format

This, however, does not make JavaScript an interpreted language;
strictly speaking, it makes JavaScript rather a compiled language
because JavaScript bytecode would then be a different language.

I would agree, if the bytecode was used for exchanging Javascript
programs, and not only internally in the interpreter.

If JavaScript was only an interpreted language (e.g. like bash), source
code would be executed line by line and only if a line was reached it
would be checked for syntax errors prior to execution.

That's a very narrow view of what an interpreter is. What you describe
is characteristic of an *interactive* interpreter, or just something
with a very simple grammar. But even then, as I'll show later, you
*can* do exactly that with ECMAScript.

However, JavaScript syntax errors are recognized before the script
is run.

So does Perl, which I still maintain is (primarily) an interpreted
language. So as an argument, it won't change my mind

The reason is that a compiler checks the source code for
correctness, compiles it into bytecode if it is syntactically
correct and then the resulting byte code is interpreted,
i.e. executed, by the JavaScript VM (which may result in runtime
errors). The compound that makes up a at least the JavaScript
JIT-compiler and the JSVM is called the JavaScript engine:

<http://lxr.mozilla.org/mozilla/source/js/src/README.html>

I assume you mean that this is an argument for JavaScript being
compiled. Let's remember this for a little later

That's the SpiderMonkey implementation of JavaScript. It's an
efficient implementation. If one were to implement a more efficient
interpreter for bash scripts, then it would probably also parse
the script into an internal format before executing it. But that's
an implementation detail of the interpreter. It still doesn't
create an external, retainable compiled version, which means, to
me, that it is still an interpreter.

[...]
So, I'd call JavaScript, and ECMAScript, interpreted languages,
not compiled ones, because they are typically run from source
every time, and are designed to be so.

No, they certainly are not! While this is a common misconception, neither
the Netscape JavaScript Reference nor the ECMAScript Specification state
anything of the kind.

I never claimed that they did, but that I would, based on the design
choices and typical use of JavaScript, classifiy it as designed as an
interpreted language.

Especially, ECMAScript Ed. 3 contains the following paragraphs:
...
| The intent is that the incoming source text has been
| converted to normalised form C before it reaches the compiler.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is one of four occurences of words starting with "compile" in
ECMA262v3. The meaning of "compiler" in this is not defined anywhere
(this is the first occurence of the four).

| 15.10.2.2 Pattern
| [...]
| Informative comments: A Pattern evaluates ("compiles") to an internal
^^^^^^^^^^^^^^^^^^^^^^

Let's not confuze Regular Expressions, which are a language of their
own that are embedded in Javascript, with Javascript itself. Regular
expressions are traditionally converted to a more efficient internal
representation before using, and that transformation is traditionally
called "compilation". That is the behavior of regular expression
libraries, as included in many other languages as well. It's also
somehow reasonable (but I can see a problem for me coming up), because
the compiled version of the regular expression *is* stored and then,
later, interpreted, possibly several times.

My problem is that the compiled version of a regular expression is not
*external* to the Javascript interpreter ... although it is to the
regular expression interpreter. At least, a user (in this case another
program instead of a person) can wait arbitrarily long between
compiling and running the result of the compilation.

While the former may be debatable as a proof because "to compile" can have
different meanings (including, but not limited to: to construct, to build,
to contain, to compose), the relation between compilation and syntax errors
is made quite visible here, so ISTM that the process a source code compiler
(more exact: the source code parser which part of the compiler) performs is
referred to here as well.

Parsers can be part of interpreters too (with my definition of
interpreter . Actually, they pretty much have to be part of any
program that understands source code.

Furthermore:

| 16 Errors
|
| An implementation shall not report other kinds of runtime errors early
| even if the compiler can prove that a construct cannot execute without
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| error under any circumstances. An implementation may issue an early
| warning in such a case, but it should not report the error until the
| relevant construct is actually executed.

This uses "compiler" in much the same way as the first use (and it is
the fourth and final occurence

However, you left out the *first* paragraph of that section:
---
An implementation should report runtime errors at the time the
relevant language construct is evaluated. An implementation may
report syntax errors in the program at the time the program is read
in, or it may, at its option, defer reporting syntax errors until
the relevant statement is reached. An implementation may report
syntax errors in *eval* code at the time *eval* is called, or it may, at
its option, defer reporting syntax errors until the relevant
statement is reached.
---

Now, remember that SpiderMonkey caught syntax errors when first
parsing the program into its internal bytecode. I said then that it
was an implementation choice of SpiderMonkey, not a requirement of the
language. This says so, much more directly.

This is, if anything, characteristic of an interpreted language.
Together with the existence of "eval" and even just calling it a
"scripting language", it convinces me that JavaScript was designed
as an interpreted language (again, with what I consider the most
reasonable definition of being an interpreted language: that
each execution starts from source code).


So, *if* the distinction between a compiled and an interpreted
language exists and makes any sense, then I will put JavaScript and
ECMAScript into the interpreted group. However, if the distinction was
always clear, we wouldn't have this discussion.

Let's try to imagine three groups of languages:

1) languages that are always compiled
2) languages that are both compiled and interpreted
3) languages that are always interpreted

Then I doubt there is any language that, by necessity, has to be
in either group 1 or 3. I have seen interpreters for C and Java source
code, and compilers for the Bourne shell and DOS .bat-files. Any
language can be interpreted. Any language can be compiled.

<URL:http://root.cern.ch/root/Cint.html>
<URL:http://koala.ilog.fr/djava/>
<URL:http://www.comeaucomputing.com/faqs/ccshfaq.html>
<URL:http://www.softempire.com/batch-file-compiler-downloads.html>

A distinction must be on what the *typical* or *intended* use of the
language is, not what possbile, or actual but rare, exceptions might
exist. Both C and Java are typical compiled languages. Both sh-
and .bat-language are typical interpreted languages. A language
like OCAML can reasonably claim to be somewhere in the middle.


All source program managing programs needs the ability to parse the
source code, both compilers and interpreters included. For a few
languages, an interpreter can do this incrementally as the program is
executed (typically languages also intended for interactive use, with
simple, command-like statements). Other languages have more
complicated grammars, and an interpreter need to parse entire files at
once, or even entire groups of files. They will then store the parsed
program internally in some format. They might even pick an efficient
representation, which could be some sort of bytecode.

You might call transformation "compilation", but when you always have
this compilation followed by execution, it *is* just a part of an
interpreter, an accident of implementation.


So, back to my way of distinguishing compiled and interpreted
languages:

What characterizes a compiled language is that the compiled program
can be stored arbitrarily long, and then executed several times.

What characterizes an interpreted language is that each execution
starts from the original source code.

Typical usage of Javascript puts it clearly in the latter category.


/L

 

[Thomas 'PointedEars' Lahn]

That is the flaw in your argumentation. You distinguish between begin
and end of the process where you should distinguish between input/output
pairs. There are languages, if seen as a whole, that are not either
compiled or interpreted but both (first) compiled and (then) interpreted,
as it is e.g. with JS, and with Perl (ref. `man 1 perlcompile').

As you later point out, that would be a compiler for Perl and an
interpreter for Perl parse trees. I say it's just Perl having
a parser for Perl available that is also the same parser being
used by the Perl interpreter. [...]

But the JavaScript compilers available (e.g. for Netscape Enterprise Server)
can work independent of the JavaScript Virtual Machine being used to
interpret the bytecode it creates from source code, and it is possible to
create JavaScript platform-dependent binaries (as with some Java compilers,
BTW). The JS compiler is packaged with the VM for use in HTML UAs and is
used there JIT, that's all. But JavaScript has always been more than just
a browser language, it is only that few people recognize(d) this.

[...]
I'd say that JavaScript was designed for interpretation rather than
compilation.

Apparently you did not understand what I wrote. JavaScript[tm] was
*designed* as a language specifying human-readable source code to be
compiled into bytecode and then have this bytecode interpreted by a
Virtual Machine in the first place (which makes it cross-platform).

Where do you find this (that JavaScript was designed for being
parsed into bytecode)?

For example in the JavaScript Reference Implementation documentation
that I mentioned earlier.

It is designed for ease of writing and being cross-platform, I can
agree on as much, but whether the actual implementation of it shoud
use bytecode or not is not something I can read from the link you
give,

It's quite clear described there in the section "Design walk-through".

nor from the ECMAScript standard.

Which is not surprising as I am talking about JavaScript.

What is clear, is that the primary format of exchange of Javascript
code is source code, and that every web page containing Javascript
(as you say, the orignal design target of JavaScript)

which got a sibling called Server-side JavaScript on Netscape Enterprise
Server shortly after and then emerged into JavaScript and its siblings used
in many different user agents, including Adobe Acrobat, as server-side
JScript in ASP and so on,

will start from source code every time it is read. While there might
be internal compilation in the interpreter, it is hast the I/O
characteristics of an interpreter.

No, the JSVM (i.e. the interpreter module of it) works independent
of the JS compiler; it is designed to interpret its output.

What is this "JavaScript bytecode" language?

It is the language that the JavaScript VM (JSVM) understands. If you count
machine languages as programming languages (I do not, BTW), you have to
accept that JavaScript bytecode is a programming language for the JSVM.

Is it standardised anywhere?

I don't think so, but that does not matter because we are talking about
JavaScript (yes, proprietary!), not ECMAScript (standardized). There is,
however, a reference implementation, so there has to be a documentation
about this, even if only in the source package (which I did not examine
yet).

Or maybe it is just an artifact of the implementation of one interpreter.

Obviously you don't understand that I am discussing one implementation
only, not ECMAScript nor JScript, here. However, two things have to be
considered:

1. JavaScript was the first scripting language of its kind. JScript
followed and what was common among both of them and ready to be
standardized, went into ECMAScript. It would not make sense that
a JScript or pure ECMAScript implementation would be any different
in this regard.

2. It is highly unlikely that any ECMAScript compliant engine will work
any different because so far they are as fast as SpiderMonkey, sometimes
even faster. Would the source code be not compiled first, they would be
considerably slower, given the same source code.

I know that Rhino uses an internal JavaScript bytecode, and so does
SpiderMonkey.

SpiderMonkey is the Netscape JavaScript Reference Implementation by
Brendan Eich (inventor of JavaScript), written in C, used in Mozilla
Web browsers since generation 2 (Netscape 2+ and Mozilla.org browsers).
The current version is 1.5.

Rhino is an open-source implementation of JavaScript written entirely
in Java. It allows for accessing Java objects in JavaScript and can
generate both Java and JavaScript bytecode from JavaScript source code,
in contrast to SpiderMonkey which generates only JavaScript bytecode
from JavaScript source code.

[...]
Resin even has a compiler from Javascript to Java
bytecode, yet another bytecode format

<URL:http://www.caucho.com/articles/990129.xtp>

Yes, but we are talking about _JavaScript_ bytecode, not JavaScript
source code compiled into Java bytecode. The former bytecode is to
be interpreted by a JSVM, the latter one by a JVM.

I would agree, if the bytecode was used for exchanging Javascript
programs, and not only internally in the interpreter.

It was and is used, yet less often than the JIT-compiler in UAs.
STFW for "JavaScript compiler", e.g.

The reason is that a compiler checks the source code for
correctness, compiles it into bytecode if it is syntactically
correct and then the resulting byte code is interpreted,
i.e. executed, by the JavaScript VM (which may result in runtime
errors). The compound that makes up a at least the JavaScript
JIT-compiler and the JSVM is called the JavaScript engine:

<http://lxr.mozilla.org/mozilla/source/js/src/README.html>

I assume you mean that this is an argument for JavaScript being
compiled. [...]

Yes, of course, just because it is so.

[...]
So, I'd call JavaScript, and ECMAScript, interpreted languages,
not compiled ones, because they are typically run from source
every time, and are designed to be so.

No, they certainly are not! While this is a common misconception,
neither the Netscape JavaScript Reference nor the ECMAScript
Specification state anything of the kind.

I never claimed that they did, but that I would, based on the design
choices and typical use of JavaScript, classifiy it as designed as an
interpreted language.

Your selectively narrow view on programming languages is your problem,
not mine.

This is one of four occurences of words starting with "compile" in
ECMA262v3. The meaning of "compiler" in this is not defined anywhere
(this is the first occurence of the four).

What matters is that a compiler used is mentioned. Of course you don't
find an interpreter mentioned because it does not belong there: ECMAScript
spec does not need to define how that generated bytecode looks like and
how it is to be interpreted, that is up to the implementation and *its*
spec.

| 15.10.2.2 Pattern
| [...]
| Informative comments: A Pattern evaluates ("compiles") to an internal
^^^^^^^^^^^^^^^^^^^^^^

Let's not confuze Regular Expressions, which are a language of their
own that are embedded in Javascript, with Javascript itself. [...]

While the former may be debatable as a proof because "to compile" can
have different meanings (including, but not limited to: to construct, to
build, to contain, to compose), the relation between compilation and
syntax errors is made quite visible here, so ISTM that the process a
source code compiler (more exact: the source code parser which part of
the compiler) performs is referred to here as well.

Parsers can be part of interpreters too (with my definition of
interpreter .

Yes, exactly. *Your* definition.

Actually, they pretty much have to be part of any program that understands
source code.

But this parser, and I'm talking about _/*JavaScript*/_ [tm]'s, is not.
Proof has already been given but you are too ... stubborn to see it.

Maybe I did not make myself clear: I do not consider JavaScript a compiled
language only, and I do not consider it an interpreted language only. It
is a hybrid language in this regard, first compiled, then often
interpreted. But iff one wants to have it either black or white, I'd say
it is a compiled programming language, because it *is* compiled, _not_
interpreted(, first).


PointedEars