Limitations

Streamline allows you to take advantage of all features of the Javascript language in your code. The transformation engine knows how to deal with loops, exception handling, ... and tries to generate code that preserve the semantics of the code that you write. There are nevertheless a few limitations and a few things that you need to know.

Unsupported Javascript constructs

Labeled break and continue statements are not supported yet. For example:

outer: // unsupported :-(
for (var i = 0; i < 5; i++) {
  for (var j = 0; j < 5; j++) {
    if (cond) break outer; // unsupported :-(
    ...
  }
}

switch/case statements that flow into each other are not supported either, except if there is no code between them. For example:

switch (exp) {
case 1: // supported :-)
case 2:
  f1();
  break;
case 3:
  f2(); // unsupported :-(
case 4:
  f3();
  break;
}

Note: these limitations can be overcome. It just requires more work and testing. I'll probably add support for labeled statements at some point but I don't intend to fix the switch/case limitation at this point as it encourages questionable programming style.

Evaluation order

Streamline guarantees correct sequencing of statements but does not guarantee that all the subexpressions of a given statement will be evaluated as you would expect them to be. For example:

f(g(1), h(_, 2));

Streamline will generate code that evaluates the second argument (h(_, 2)) before the first one (g(1)). As a general rule, streamline will evaluate asynchronous subexpressions before the synchronous ones. So you should not write code that relies on the order in which subexpressions will be evaluated (this is dangerous practice anyway).

On the other hand, streamline does preserve sequencing and lazy evaluation of logical and ternary operators. For example:

x = g(1) && h(_, 2);
y = g(1) ? h(_, 2) : k(_, 3)

In these statements, g(1) will be evaluated first and h(_, 2) will not be evaluated if g(1) is false.

Note: the transformation engine could be modified to preserve evaluation order in all cases but then the generated code would grow significantly and would be harder to read and debug. I find it preferable to generate lean code and require the programmer to stick to sane programming practices.