13 Replies to “JavaScript 2 / ECMAScript Edition 4”

  1. Brendan,
    I am looking forward to the introduction of let blocks, they make up for the simple scoping semantics of the original javascript in a non-intrusive way. I think they were a sound decision.
    One thing I am still hoping will be rethought is the package mechanism that the ECMA TG1 is proposing. A “first class” package mechanism isn’t really appropriate for javascript in my opinion. And it seems to me that the package mechanism being proposed is simply a hot copy of Java’s. I work with Java on a daily basis, and we have weekly technology discussions at my company where the broken semantics of Java’s package mechanism and package access restrictions have been a frequent topic of conversation. They very frequently make a mess of things, in fact.
    When I mentioned in my previous writings that I thought javascript was in need of a better package and extension mechanism, I was honestly hoping for a bit more creativity than borrowing the broken ones from Java.
    Let’s consider for a moment the fact that JavaScript is a particularly web driven language. How about using fully qualified uniform resource locators for package name spaces? This could very easily double as a mechanism for inclusion during runtime compilation, and inheritly introduces hierarchial name spaces.
    I have some ideas as to how to work this out, I will attempt to work out the kinks them and write about them soon.

  4. Honestly, I find that a little bit obnoxious.
    functions effectively are lambdas, and with the combination of lambda and let block behavoir, I don’t see a reason to add more annoyingly implicit and unclear syntax to the language.

  5. Hi Brendan,
    I’m a recent convert to javascript in a big way (using it for server as well as browser side) but I really am disappointed with the direction thats been taken for JS2. I’m firmly in the ‘leave it alone’ camp and after reading through your slide set, I wrote a short rant on my blog about why 🙂
    While I appreciate that the JS2 path seems to be firmly laid down, it would be good if you would write some more about the ‘movitations” for the big changes prosposed in JS2, especially why it should move into ‘programming in the large’ as thats one set of functionality I just cant see the need for.

  6. It is possible to have a “exit” function in js2 ? Like the die(); or exit(); from php

  7. After reading public TG1 resources about let syntax I understand that optional return in functions may be not very nice idea for let statement.
    But the short lambda syntax is a must have for JS, if it want’s to look like functional language. Every type in ES has now short literals (even dates and XML), but only function (the main type) seems still discriminated. I just wonder why.
    conisder:
    var obj = {a:”Hello”}
    var arr = [1,2,3]
    var date = 2005-11-02
    var regex = /^hi/
    var num = 123
    var str = “hi”
    var func = function(a){return a+a};
    As you can see the function is the longest here – two times longer.
    So I can’t say that functions are “first-class” citizens in JS, they are still “second-class” 🙂
    Most of languages has short function syntax ( {a| } in Ruby, {} in Perl, [] in Smalltalk, ( ) in Haskell and lot of others). It seems that only Python with long and non-lexical lambda is exception here.
    Moreover, looking at ES4 type declarations gives the same strange feeling – function types is just to long compared to other types.
    Even C does it better than JS here. And C is not script language, and doesn’t have closures at all.
    We already using the (){} syntax in our company with modified SpiderMonkey and MTASC compilers. The modification is just in lexer, and doesn’t breaks anything. The only pain is to back-migrate code each time when it needs to be delivered to existing interpreters.
    Also let expressions are not total replacements for inner blocks, they are still not expressions (no return values), and they cannot be used as blocks for forEach, map, filter and alikes (cause no arguments can be passed to let-blocks).
    Vassily

  8. Scott: thanks, as I have noted to you over IRC, we are not done with packages yet.
    maks: there are at least 134 “Ajax” libraries, with line-counts in the 10KSLOC to 100KSLOC and beyond. These libraries are used by equally large apps. This *is* large scale programming — the horse is out of the barn.
    Nicolae: what exactly does your proposed exit() do? It had better not exit the browser, for the browser JS embedding. If it’s meant to terminate the top-level script, you might use throw instead.
    Vassily: regarding “Also let expressions are not total replacements for inner blocks, they are still not expressions (no return values), and they cannot be used as blocks for forEach, map, filter and alikes (cause no arguments can be passed to let-blocks).”
    You’re right that let expressions are not function definitions or lambda expressions, but they are certainly expressions — a let expression is evaluated to a result each time control flow reaches it. It seems to me that you are mixing up the meaning of “block” in more C-like languages (BCPL was an expression language) with the more lambda-like, implicitly quoted, evaluated by messaging (essentially by invocation) Smalltalk-ish blocks now popular in Ruby.
    We are not going to add another kind of function object to JS2/ES4.
    We could have syntactic sugar for lambdas. I will try to persuade the committee with a straightforward proposal.
    /be

  9. Thanks for clarification with let exressions. Checked in JS1.7 – they are actually provide evaluated to some value.
    js> let(a=1){a+a};
    2
    However trying to use this value produces an error.
    js> var b=(let(a=1){a+a});
    typein:15: SyntaxError: missing : after property id:
    typein:15: var b=(let(a=1){a+a});
    typein:15: ……………..^
    But may that is just because of beta-state of JS1.7. Will wait and see.
    >>We are not going to add another kind of function object to JS2/ES4.
    Of course we do not need another kind of functions, lambda in current JS is powerfull enough, better then pythonic. The only proposal was shorter syntax, like in Ruby and Smalltalk, only JS-way
    So,just
    [2,3,4].forEach(( it, i){
    print(it + “:” + i)
    })
    instead of
    [2,3,4].forEach(function(it, i){
    print(it + “:” + i)
    })
    Thanks for taking my point, hope comittee will like it too.
    Vassily

  10. I find that too obscure and relying on a space mmm…
    function obfuse(){
    obfuse=arguments.callee=function(){alert(“K.I.S”)}
    arguments.callee();
    }
    For me, any shorter would lose meaning; although my vote is for this, just shortening function to func and arguements(which will be used a lot going forward):
    func obfuse(){
    obfuse=args.callee=func(){alert(“K.I.S”)}
    args.callee();
    }

  11. How about this:
    let obfuse() {…}
    The current ES4 let proposal has ‘let function’ and ‘let const’ variants, but the keywords pile up with no obvious need for disambiguation.
    /be

  12. ECMA TG1 have reached an agreement on how to write briefer functions, but it’s not based on ‘let’. Instead, as with ‘let’ blocks vs. ‘let’ expressions, we are going to support
    function cube(x) x*x*x
    This is an extension to existing syntax, so support for it won’t break existing code. The value of the expression is the function’s return value. The comma operator supports sequencing.
    We reckon that ‘return’ and body bracing are the syntactic costs to eliminate in the relatively verbose function “literal” shown by Vassily’s first comment. We do not propose to provide a shorter keyword than ‘function’, in order to avoid breaking existing programs that use, e.g., ‘fun’ or ‘func’. We are not in favor of backslash before the left parenthesis as a short-hand.
    /be

Comments are closed.