Named arguments can help making function calls more understandable in cases where the meaning of arguments is not immediately obvious. For example this:

document.importNode(elem, true)

Is probably not as clear as this:

document.importNode(elem, deep=true)

When using named arguments, the order of the arguments doesn't matter, as long as a value is provided for all required parameters. Both named an unnamed arguments can be used in the same call (as shown above), but named arguments must follow after all unnamed arguments.

A yield statement turns a function into a generator, which lazily generates a list of values. Each yield in the function returns a single value. The state of the generator function is preserved, so when the next value is requested, the execution of the generator function continues immediately after the yield.

An example (taken from MDC):

function simpleGenerator(){
  yield "first";
  yield "second";
  yield "third";
  for (var i = 0; i < 3; i++)
    yield i;
}

var g = simpleGenerator();
print(g.next()); // prints "first"
print(g.next()); // prints "second"
print(g.next()); // prints "third"
print(g.next()); // prints 0
print(g.next()); // prints 1
print(g.next()); // prints 2
print(g.next()); // StopIteration is thrown

The generator can also be used in for each-loops as if it was an ordinary array:

function numGenerator(){
  for (var i = 0; i < 3; i++)
    yield i;
}

for each (var x in numGenerator()) {
   console.log(x); // prints 0,1,2
}

(The for-loop catches the StopIteration internally in this case, as it just signals the end of the list.)

Generators are also known in languages like Python and C#. Mozilla have native support for generators, but no other browser I know of have.

Caveat

Generators are pretty cool, but there is one drawback. The compiler output is pretty inscrutable, since it requires somewhat convoluted code to support generator semantics in downlevel JavaScript. This is not a problem when the code runs, but may make it unpleasant to debug generator function produced by Mascara.

Generally Mascara aims to produce output code which is as clear and pretty as possible, but in the case of yield this is not really very clear.

Anyway, I would love feedback from Mascara users if you find 'yield' useful, and whether the generated code is acceptable.

    var x = "hello";
    package {
        var x = 17;
        console.log(x); // writes 17
    }
    console.log(x); // writes "hello"

Anonymous packages are useful for ensuring that a block of code doesn't pollute the global namespace. If you have several anonymous packages, they are also hidden for each other.

Behind the scenes, anonymous packages are transformed into this pattern:

   (function(){
       ...
   })();

Newest feature is support for "Open Definition". Place the caret on an identifier (variable name, property, function name, whatever) and hit F3 (or select "Open Definition" on the right-click context menu). The editor will jump to the definition of the identifier, even if it is a different file.

It also works with classic JavaScript code, by the way [1].

This feature is a major milestone because it shows deep integration between the editor and the compiler AST. Additional code-aware features like "Show References", "Show Call-graph" etc. can be built upon this infrastructure.

It also makes development much more pleasant and fun.

[1] As long as you don't get too fancy.

Sometimes you just need a single, unique object. The easiest way to achieve this is an object literal. Example:

    var x = { 
              _v:1, 
              get_v : function(){ return this._v; }
            };
    var y = x.get_v();

This common pattern is now fully supported including type verification and code completion.

Furthermore you can now use getters and setters in object literals, which is some of the new syntax syntax in ECMAScript 5:

    var x = { 
             _v:0, 
             set v(x){ this._v = x; }, 
             get v(){ return this._v; }
             };
    x.v = 100;
    var y = x.v;

(Note that the getter/setter syntax is slightly different in object literals - you don’t need the function keyword here.)

Object literals are most convenient when you only need a single instance of an object. For example a global object literal is the equivalent to the singleton pattern as in Java - but the syntax is much simpler.

The limitations are that an object literal does not support inheritance. If you need that, a class is better.

Definite assignment analysis ensures that no variable is used before it has been assigned a value. This can prevent some subtle bugs, and will in general make code more clear. It is inspired by languages like Java and C#.

Consider this code:

var x : String;
if (a>10) x = "Hello";
else if (a<10) x = "Goodbye";
alert(x);

There may be subtle bug in this code. What if a has a value which is exactly 10? In that case, x will never be assigned a value, and the undefined value will be sent to the alert function.

Now, that may or may not be a bug depending on the intentions of the developer. However it is easy to miss that the variable in some case will never be assigned a value.

In the newest Mascara, you will for this reason get a compiler warning on the last line, because x may not be assigned a value at that point.

The right way to fix the code depends on the intention. If the if branches were supposed to cover all eventualities, then add an else or change the else if into an else.

If the variable should be null if no of the conditions are met, then just initialize it to null in the first line. (The null value is somewhat equivalent to the undefined value. However, there is the important difference that null indicates that a legitimate variable has been explicitly assigned the null value, while ‘undefined’ usually indicates an error or missing variable.)

To be clear, this improvement is not a part of the ECMAScript spec, it is a Mascara-specific extra verification. It will probably never be part of the ECMAScript because of backwards-compatibility issues. As always, I appreciate feedback on this feature.

    
    if (2+2=5) {
      switch (true) {
        case false:
            var location;
      }
    }
    location = "something"

Here the var-statement does occur before the first reference to the variable, but the var-statement is nested inside if- and switch-blocks, which makes it easy to miss, and it is counter-intuitive that a deeply nested statement will change the meaning of a variable in an outer block. Furthermore, the statement cannot possibly ever be executed as the code looks now - but the var still have effect.

All this is highly counter-intuitive, and makes it unnecessary tricky to read code. Therefore Mascara provides a simple fix.

The new rule is: A local variable can only be accessed in the same block, or in nested blocks inside the block where the variable is declared with var.

E.g. this is legal:

    var location = "hello";
    location = "goodbuy";

And this is legal:

    var location = "hello";
    if (something) {
        location = "goodbuy";
    }

And this is legal:

    if (something) {
        var location = "hello";
        location = "goodbuy";
    }

But this is not legal, because the variable is used outside the block with the var-statement:

    if (something) {
        var location = "hello";    
    }
    location = "goodbuy";  //WARNING!

The last example will generate a ´Name not found: 'location' in function scope´-warning.

This is a small fix, but it is the accumulation of small things like these which makes the difference between long nights of bug-tracing, enjoyable development of new features.

Clarification: this does not change the run-time semantics of the var statement, it is just a compile-time verification which avoids some confusing and potentially buggy patterns. It is therefore not equivalent to the proposed 'let'-scopes which does change the semantics, e.g. by allowing you to 'shadow' variables declared in an outer scope.

I sometimes forget to post on the blog when a new version is released - sorry about that! We are now up to version 1.7. Everyone should upgrade, since each new release contains bug-fixes and improvements. (The Eclipse plug-in is also regularly updated, but should still be considered alpha stage. You will get the updates automatically through Eclipse, if you have it installed.)

Mascara version 1.7 in particular have some improvements which eliminates groups of subtle bugs which traditionally plagues JavaScript development.

The first one I will mention is the handling of the "var" statements.

In JavaScript, the var statement declares a local variable. If you refer to a variable which have not been declared with "var" in the current function, the runtime looks in the outer scopes and the global scope.

Now the subtle issue: A variable is resolved to a local var even if the "var"-statement occurs after the reference to the var.

Say:

function f() {
    location = "somewhere"; // does this assign to a local or global variable?

    {..lots of code...}

    var location; // this statement means that first line refers to a local.
}

The 'var' may even be defined deep inside nested statement block like ifs and loops - it still changes the meaning of the "location" in the first line of the function.

This is obviously bad. It breaks the basic assumption that you shouldn't have to look forward inside a function to determine if a variable is a local or global. Furthermore, no other language works like JavaScript in this case. Most languages will simply not allow you to use a local variable before it is declared. (Python does have semantics closer to JavaScript, but in a subtly different way which avoids the kind of bug JavaScript is prone to.)

The solution for this is simple: Mascara yields a warning if you read or assign to a local variable before it is declared with 'var'.

You may wonder why I made it just a warning which can be ignored, rather than a downright compiler error?

The reason is that some code (legacy code, third party libraries) may use this pattern for whatever reason, but still be thoroughly tested and work correctly. So you might not want to fix it, or you may want to fix it at your own lesiure, while still being able to use the code in the meantime.

Since it is a prime directive for Mascara to work well with libraries written in classic JavaScript, and allow a painless upgrade path from classic JavaScript, this is an important consideration.

Therefore the general principle for warning/error distinction in Mascara is that if something could just theoretically work if the developer knows what they're doing, it is just yields a warning. Errors is reserved for things which could never possibly work, like syntax errors or inconsistent types.

Anyway, hope you enjoy the improvements, and have fun coding.

Therefore I have developed an Eclipse plugin with Mascara language support as the first example of integrated editor support. (Support for other editors/IDE's may follow in the future depending on user interest, although I'm not promising anything at this point.)

The Eclipse plugin is still in the alpha stage which means it has bugs and missing features, and you basically should't expect to be able use it for serious work yet. It is released mainly as a proof of concept, and because many users like to see how its going.

How to get to "Hello world" using the Mascara Eclipse Plugin

1) Install python 2.6 if you dont already have it.

2) Install the plugin
Open eclipse 3.5 (earlier versions may work but I havent tested it) and install the editor support via:

Help -> Install new software -> Add
In the "Add site" dialog:

Name: Mascara editor
Location: http://mascaradownload.appspot.com/releases/mascaraeclipse

Check off "Mascara editor" in the list, and click Next. The feature shound now install automatically.
    
You will get a warning that the content is unsigned. Press OK.
    
When prompted to restart Eclipse, choose OK
    
Note: On Unix, the plugin assumes python is located in /usr/bin. If it is located somewhere else,
you have to configure it on the preference page for Mascara (Window->Preferences).

3) Create a new project in Eclipse:

File -> New -> New project
(Just select a standard project: General -> Project. There is no specific Mascara project type yet.)

4) Create a new file:

File -> New -> Other
Select Mascara / New Esx File.

The file shoult have the ".esx", extension, so call it something like "main.esx".

5) Write something like this in the file:

import browserapi;
window.onload  = function() window.alert("hello world");

(Here you should hopefully notice syntax coloring and language aware code completion! At least halfway working.)

6) Click "Run" (the green arrow)

The first time run is clicked you get a wizard to create a run configuration:

In Select Esx source, the new file is selected by default

Select Create new HTML file. This will generate a new HTML file with a script reference to the (compiled) esx file. Click Next.

The dialog suggest where to save the HTML file. Click Finish.

7) The default browser should now start with the HTML page and the included script, displaying the hello world alert.

Have fun! As always, questions or suggestions welcome.

Bonus: Hello world using JQuery

If you like JQuery you may prefer to write something like this instead:

import browserapi;
import jqueryapi;

$(function(){
    $("Body").append(
        $("<div>Hello world</div>")
        .fadeIn(1000));
        });

You will have to add a <script>-element to the HTML referencing the JQuery library before running. You can dowload JQuery, or just hotlink to the hosted version:

<script src ="http://code.jquery.com/jquery-1.4.2.min.js"></script>

Happy coding!

translate.py somefiletocompile.esx --server 9000

The number after the --server argument is a port number (can be any number not in use) where the compiler process will listen. The first time, the compiler is initialized (which may take some time)
but afterwards the script will detect that the compiler is already running at the port, and dispatch the compilation job, which should be much faster.

Have fun!