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!

As a proof-of-concept I have implemented code completion in the online "try-it" editor over here. Of course the online editor is not suited for serious use, but it does provide a nice showcase for what is possible.

Code completion is disabled in the editor by default. It is enabled by clicking the "magic wand" icon leftmost in the toolbar. (The suggestions may be somewhat slow to appear, since the editor has to hit the server to get the suggestions.)

An example of how it looks when i start writing the letter "f":

You can cycle through the suggestions using the up/down arrow keys. A suggestion is selected by hitting enter, or clicking it with the mouse.

The suggestion box appears automatically when you start typing, or it can be forced to show by pressing control+space.

A limitition in the current implementation is that the autocompletion usually wont work if there is compilation errors in the code. We are working on that issue.

A related experimental feature is support for documentation comments. If a variable or function is preceeded by a comment starting with /** (note: two stars rather than the usual one), the content of that comment is displayed as help related to the suggestion for the function. As in this example:

(Tags like what is known from doc-comments is Java or C# is not supported yet, though.)

Any feedback welcome!

Therefore it has always been a bit embarassing with the generic "Parser error at or near..." message in the case of syntax errors.

It just tells you that some character is wrong, not what you are supposed to write instead. Especially when learning a new language this can be infuriating. Particularily for people (like me!) who like to explore by trial and error.

In the latest Mascara release, parser error messages have been improved so they now suggest what syntax would be allowed instead of the erroneous character.

E.g. if you write

class {}

You get:

Syntax error. Unexpected '{'. Expected identifier

This tells you that an identifier is required after the keyword "class", which is hopefully a lot more useful than just the message "Parser error at or near '{'".

In many cases multiple options are legal at a given point. If you write:

class A()

The compiler will report:

Syntax error. Unexpected '('. Expected one of: '!', 'implements', 'extends', '.<', ';', '{'.

That is quite a number of tokens to choose from, but hopefully it gives a much better hint about how to fix the syntax error.

Sometimes it can be slightliy less obvious where the actual error is. Consider this:

var x =
var y = 100;

In this example I forgot to finish the first line. However the compiler will flag the "var" on the second line with "Unexpected var. Expected expression." This is because it would be legal to have the assignment value on the next line - but then "var" is not a legal expression, which causes an error.

In general it is a difficult problem to give helpful error messages for syntax errors, but hopefully these improvements is a step in the right direction, and will make it more fun to explore the language by trial and error.

A private member is accessible only by methods in the same class. A public member is accessibly by everyone, just as members always are in classic JavaScript.

class A {
    public function famous() {};
    private function secret() {};
    private function test() {
         famous();  //OK because famous is public  
         secret(); //OK because we are members of the same class
    }
}
var a = new A();
a. famous(); //OK
a. secret(); //ERROR, secret is not accessible from here

Members are public by default.

Static members can also be private. Private static methods can access private instance members in the same class and vice versa.

Constructors can also be private. With a private constructor it is not possible for other classes to create instances of the class. Static methods on the same class are then used to instantiate and return instances of the class. This can be used to implement patterns like singleton and factory.

Have fun with encapsulation!

Download here.

In short, getters and setters are special functions which are invoked the same way a variable or property is read or assigned.

Here is an example of a getter:

//defining a getter function x
function get x() { return 7; }
// the function is invoked by accessing the variable value:
var a = x;  // (a is assigned the result of calling get x, i.e. 7)

This is pretty useful for encapsulating member access.  A setter is the corresponding function which emulates assigning a value to a property or variable:

function set x(x) { alert(x) }
x = “hello”; // set x is invoked and shows an alert box with “hello”

Getters and setters (together known as “accessors”) are useful for various forms of encapsulation. For example we can perform validation on input, we can change the internal representation without changing the interface, or we can trigger events when a property is changed.

Getters and setters often appear together, but we can emulate read-only properties by only providing a getter, or (less commonly) write-only properties by just exposing a setter.

The new addition is that ECMAScript 5 defines a syntax for gettes and setters in object literals. Example:

var ecoStorage = { 
    // to save memory space we only save half the value    
    _storage : 0.0, 
    get x() { return ecoStorage._storage * 2; }, 
    set x(value) { ecoStorage._storage = value / 2 }
};
ecoStorage.x = 100;
var y = ecoStorage.x; // y is assigned 100

So the accessors appear in the place of a name:value pair in an object literal.

Above we get a single object instance with the getter/setter pair. If we want to instiate multiple object, we have to create a constructor the object literal as a prototype. Hence:

function EcoStorage() {}
EcoStorage.prototype = {
    _storage : 0, 
    get x() { return this._storage * 2; }, 
    set x(value) { this._storage = value / 2 }
};
var storage1 = new EcoStorage;
storage1.x = 100;
var y = storage1.x; // y is assigned the value 100

This approach is also supported in Mascara, however I can’t say I find the syntax particularity attractive. I appreciate the flexibility declaring prototypes explicitly, but the syntax is not elegant.

The idiomatic way to do the same in Mascara is to use classes:

class EcoStorage {
    var _storage : double = 0;
    function get x() { return _storage * 2; }
    function set x(value) { _storage = value / 2; }
}
var s = new EcoStorage;
s.x = 100;

Note the slightly different syntax (function get instead of just get) for getters/setter when they appear outside of object literals.

The ECMAScript 5 spec only allows getters and setters in object literals. However there is a low-level way to defining getters and setters through the new Object.defineProperty() method. This requires support in the JavaScript engine and is therefore not available in Mascara. It is not necessaray either, since Mascara supports the more straightforward syntax shown above.

Getters/setters in classes and as stand-alone functions has been supported in Mascara for a while. The ES5 compliant syntax for getters/setters in object literals is new in Mascara 1.2

Have fun!

They work as you would expect very much like interfaces in Java and C#. Basically they describe a set of methods that any class that implements the interface must provide implementations for.

Interfaces may contain function and getter/setter declarations, but not variables or nested types. (Hence ECMAScript interfaces does not allow constants as in Java). Declaration are just function signatures without a body.

Example:

interface Moveable {
  function moveTo(x: int, y:int) : void;
}
class DialogBox implements Moveable {
    function moveTo(x : int, y:int) : void {
        // implementation
    }
}

Interfaces can inherit from multiple other interfaces, and classes can implement multiple interfaces.

Syntax is defined in the documentation.

Since this is not a general introduction to parameterized types, it is probably best understood if you already knows parameterized types, e.g. from Java or C# (where they are called "generics", but otherwise looks a lot the same.)

An Array can by default contain values of any type. However, an array can also be instantiated with a type parameter:

var x = new Array.<int>

This creates a new array which may only contain integer values.
If you initialize with an array literal like this:

var x = [1,2,3]

The compiler will determine the Array type from the initial values. In this case it will assume an array if integers, ie. Array.<int>, because all of the items are integers.

The Array class is declared like this:

dynamic class Array.<T> { ... methods ... }

The T is the type parameter which represent the type of the items. when a new array is constructed, the type parameter T is initialized with a concrete type.

Usually the compiler requires you to explicitly provide type arguments. However Array is special-cased (for backwards compatibility), so that when it is initialized without a type argument, it defaults to use the “star” type argument, which is the "anything goes" type.

Hence new Array gets translated into new Array.<*>.

[Aside: dynamic is a modifier which indicates than any property can be attached to the object at runtime without the compiler complaining. This is supported for backwards compatibility]

Now let’s look at the type signature for every:

function every(callbackfn:(function(item:T, ix:int):boolean)) : boolean {...}

This signature may seem daunting because of the nested function signature. every takes one argument, callbackfn which is in turn a function which takes two arguments.

The first argument to the callback function is a list item, hence its type is T, the type parameter for the Array. Hence if the list is a list of ints, the function has to take an int as the first argument.

The second argument to the callback is the index of the current item in the array. This is sometimes useful to have, but we may choose to ignore this argument as we have done in the examples above.

There is a certain amount of flexibility in what callback functions can be supplied. For example, as we have seen above, arguments can be ignored/left out. However we cannot supply a function with more required parameters than the signature expects.

The parameters may be more accepting than what is declared. For example we can provide a function which expects a double as the item type:

[1,2,3].every(function(x:double) x / 2 > 2)

This will work even though T is int, since int is a subset of double. (Technically parameters are said to be contravariant.) This is allows us to supply a function without type annotations on the parameters, which is pretty nice, especially for backwards compatibility.
The return value of the callback has to be a boolean as declared. However, in the above case the compiler can figure out on its own that the callback returns a boolean, because the result of a comparison is always a boolean.

Next, lets look at filter:

function filter(callbackfn:(function(item:T, ix:int):boolean)) : Array.<T> {...}

The parameters for the callback function are the same as above. The result type is itself a parameterized type - the same as the original array. Recall that T is defined as a type parameter for Array.

Hence if you filter an array of stings, the result is always a new array of strings (although the resulting list may be empty, the type is still Array.).

Now the most complex of the function signatures, map:

function map.<Q>(callbackfn:(function(item:T, ix:int):Q)) : Array.<Q> { ... }

Note that the function takes a type parameter, which must match the result type of the supplied function, and which also determines the type the resulting array.

Hence, an explicitly typed invication of map:

x.map.<string>(function(x)x.toString()) --> results in an array of type Array.<string>
x.map.<double>(function(x) x*2) --> results in an array of type Array.<double>

Obviously, if there is a mismatch between the type parameter and the return type of the function, you get a complaint from the compiler

x.map.<int>(function(x) x.toString()) --> compiler whines!

Now, here is the nice part: The type parameter to the function can be left out, since the compiler can infer the type from the type of the supplied function.

E.g.

x.map(function(x) x.toString()) --> results in an array of type Array.<string>, no complaints from the compiler

Of course the type argument makes it explicit what type you expect, and it may help catch type errors. On the other hand you save a bit of typing when calling the method by relying on the inference.

Again, this is a question of preference. I just like that you can write in a "typeless" manner, and then later turn it into more explicitly typed code.

As shown we can get pretty far in a type safe manner without specifying types explicitly. But consider this example:

[1,2,3].map(function(x) x*2)

This function will return an array of doubles, not an array of integers which you might expect. The reason is that the parameter to the callback is not specified, so the compiler has to be cautious. Multiplication is only guaranteed to return a double (since we consider int a subset of double).

An even worse example:

[1,2,3].map(function(x) x+2)

Here we get a compiler warning, because + can be used on anything, but has different meanings depending on the types of input.

Of course we can choose to ignore the warning. But it is better style to annotate the parameters:

[1,2,3].map(function(x:int) x+2)

This results in an array of integers.

Now you may wonder why the compiler can't infer the types in this case, since it is pretty obvious for us that the function will only be called with integers. However in the general case, the compiler cannot infer the types of function parameters, since there in no general solution for that. (Future versions of Mascara might attempt to infer function parameter types, but I doubt it will be possible in all cases.)

Therefore the general advice is to at least type-annotate function parameters. Typically the compiler will then be able to figure out the rest (e.g. local variables and return value).

The flamewars have raged for decades between proponents of static and dynamic typing. My experience is that static and explicit typing is a drag when experimenting and prototyping, however the bigger and more complex a project becomes, the more valuable static analysis becomes. I really likes that Mascara allows you to begin with dynamic and implicit typing, and then gradually add static guarantees as you find it appropriate.