ECMAScript Version 4

Discussion in 'Javascript' started by Simula, Jun 28, 2005.

  1. Simula

    Simula Guest

    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
     
    Simula, Jun 28, 2005
    #1
    1. Advertising

  2. Simula wrote:
    > 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.
     
    Richard Cornford, Jun 28, 2005
    #2
    1. Advertising

  3. Simula <> wrote in message news:...
    > 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.
    --
    Stephen Chalmers
     
    Stephen Chalmers, Jun 28, 2005
    #3
  4. Simula

    Simula Guest

    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
     
    Simula, Jun 28, 2005
    #4
  5. On 28/06/2005 05:00, Simula wrote:

    > 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

    --
    Michael Winter
    Replace ".invalid" with ".uk" to reply by e-mail.
     
    Michael Winter, Jun 28, 2005
    #5
  6. Simula

    Guest

    Simula wrote:
    > 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.
     
    , Jun 28, 2005
    #6
  7. Simula wrote:
    > 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.
     
    Richard Cornford, Jun 28, 2005
    #7
  8. JRS: In article <>
    , dated Mon, 27 Jun 2005 18:30:12, seen in news:comp.lang.javascript,
    Simula <> posted :

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

    --
    © John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
    <URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
    <URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
    <URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
     
    Dr John Stockton, Jun 30, 2005
    #8
  9. Stephen Chalmers wrote:

    > Simula <> wrote [...]
    >> 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
     
    Thomas 'PointedEars' Lahn, Jul 15, 2005
    #9
  10. Thomas 'PointedEars' Lahn <> writes:

    > 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
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, Jul 15, 2005
    #10
  11. Lasse Reichstein Nielsen wrote:

    > Thomas 'PointedEars' Lahn <> writes:
    >> 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.


    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:

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

    > [...]
    > 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
     
    Thomas 'PointedEars' Lahn, Jul 16, 2005
    #11
  12. Thomas 'PointedEars' Lahn <> writes:

    > Lasse Reichstein Nielsen wrote:


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


    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 :)

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

    > 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
    --
    Lasse Reichstein Nielsen -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, Jul 16, 2005
    #12
  13. Lasse Reichstein Nielsen wrote:

    > Thomas 'PointedEars' Lahn <> writes:
    >> Lasse Reichstein Nielsen wrote:
    >>> 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').

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

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


    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.

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


    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.

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


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

    <http://www.belk.com/manual/ag/esapi18n.htm#1004693>

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

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


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


    I knew you would drag up on this which is why I wrote:

    >> 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
     
    Thomas 'PointedEars' Lahn, Jul 16, 2005
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. RC
    Replies:
    1
    Views:
    1,658
    Martin Honnen
    Jun 14, 2006
  2. V Green
    Replies:
    0
    Views:
    925
    V Green
    Feb 5, 2008
  3. PA Bear [MS MVP]
    Replies:
    0
    Views:
    1,036
    PA Bear [MS MVP]
    Feb 5, 2008
  4. MowGreen [MVP]
    Replies:
    5
    Views:
    2,082
    PA Bear [MS MVP]
    Feb 9, 2008
  5. dhtml
    Replies:
    32
    Views:
    447
    Peter Michaux
    Oct 13, 2008
Loading...

Share This Page