There is a lot of great new technology and capabilities in Olympic.  I and the rest of the team couldn’t be prouder of this release!  Beyond all the glitz and shiny newness that is getting all the attention is also an improved DekiScript engine with new capabilities.

Variable Scopes

For Olympic, we decided to make a change in how variables are scoped.  Pre-Olympic, variables have been scoped to their innermost defining context and therefore could shadow other variables without affecting them.  This is the scoping rule used by C#, Java, and many other programming languages.  JavaScript, on the other hand, scopes variables to the innermost function definition.  This design greatly simplifies the runtime in implementation and overhead.  After review, we decided to depart from our previous design and follow JavaScript’s lead.  Concretely, here is an example of what code will be affected by this change.

var x = 1;
if(condition) {
    var x = 2;
}
x;

Pre-Olympic, the above code will print 1, post-Olympic it prints 2 since the inner ‘x’ is not shadowing anymore.  The most positive impact of this change is that it is now possible to define variables at the beginning of a page and then refer to them anywhere in the body of the page following their definition.  This has been a much requested feature and I’m happy that it’s finally available!

Return Statement

Another part of the DekiScript runtime that has received significant attention is how output is accumulated and computed into a final value.  Not only is the new output buffer implementation much faster and cleaner, it also enabled the proper implementation of the semantics of the return statement, another much requested feature.

The return statement aborts the currently executing DekiScript block and produces an immediate value as output.  To some degree, the following three statements are identical.

1;
2;
return;

1;
return 2;

return (1; 2);

In all cases, the output will be 12.  In the first case, this output is produced by outputting 1 followed by 2.  In the second case, 1 is outputted and then 2 is appended by the return statement.  In the last case, nothing it outputted until the return statement appends the result of the compound expression.

However, there are cases where the output is quite different!  Consider the following three statements.

1;
<span>
    2;
    return;
</span>

1;
<span>
    return 2;
</span>

<span>
    return (1; 2;)
</span>

In the first case, only 1 is output.  More on that later.  In the second and third case, it will output 12 as well.  In all cases, the <span> element was ignored.  The reason for this is that the <span> element was not closed when the return statement was encountered and since partial XML is invalid, the entire XML block and its contents have been discarded.  That’s why in the first case, both the <span> and the inner 2 element have been omitted.  For the other two cases, the return statement ensures that the returned expression is appended to the output buffer before execution finishes for the current DekiScript block.  And hence, the expression is appended to the output that has successfully been accumulated so far.

You may wonder “why is this behavior useful?”  The answer is fairly simple: imagine you’re computing a table output, but you want to abort the entire table if an invalid value is found.  You have two choices.  Your first choice is to loop over each item in the table beforehand and validate it.  If validation fails, you show the error message. Alternatively, you have a way to abort outputting whatever you were currently computing and return an alternative result instead.  The latter case is exactly what the return statement enables you to do.  For example, the following code will do just that:

<table>
    foreach(var row in table) {
        <tr>
            foreach(var valuein row) {
                <td>
                    if(value is nil) {
                        return <strong> "A value was not set!" </strong>;
                    }
                    value;
                </td>
            }
        </tr>
    }
</table>

Try..Catch..Finally Statement

In addition to the return statement, we’ve also added the try..catch..finally statement.  It works pretty much as in any other language.  If an error occurs inside the try block, the catch block will be evaluated, otherwise the catch block is ignored.  Regardless, the finally block is always evaluated.

Since DekiScript is an expression-oriented language, we also added the !! operator to catch errors during expression evaluation.  Therefore, the following two statements are identical.

var x;
try {
    let x = f(123);
} catch {
    let x = 456;
}

var x = f(123) !! 456;

Triple-Quoted Strings

Ever found yourself in a pickle because you needed to create a string that contained both single- and double-quotes?  Up until now, you had to escape the offending character or experience parser errors.

For Olympic, we’ve added support for triple-quoted strings.  You can either use a single- or double-quote to create a triple-quoted string.  Unless you need the same triple-quotes again inside the string, you won’t need to worry about escaping anything.  Thus, the following strings are identical.

Triple-quoted strings can be used anywhere were regular strings are allowed, including for XML attributes.

Native JEM & CSS Blocks

Another improvement is the support for JEM and CSS blocks in the editor.  Just select either kind from the ‘Insert’ menu in the editor toolbar.  There is no need to encode these anymore in DekiScript blocks.  However, as before, you’ll need UNSAFECONTENT permission for JEM or CSS to be included in the page.

Conclusion

Olympic includes the best DekiScript engine we have ever shipped.  Not only does it add some great new features to the built-in scripting language that makes MindTouch so appealing, but behind the scenes, it’s new architecture is also the foundation for continued improvements in capabilities and performance.

I’m looking forward to seeing how you and the rest of the growing MindTouch community will take advantage of it!