FAQ

Personally, I would like a set of immutable collections in addition to the mutable ones, so that I don't need to copy them when passing them off to functions that are not supposed to modify them, possibly for security reasons. Both the mutable and immutable versions could implement the same set fo immutable interfaces, though. (The mutable versions would implement mutable interfaces as well.)

I really miss simple things like having a method that returns the union of two sets without modifying either of them. Java makes this unnecessarily difficult.

So you're saying you can switch the language (and, maybe, the entire philosophy of how you develop), but can't afford switching IDE?

I don't think you've understood it fully. Concurrency is one of the primary drivers of it, actually. If you have functions that are known to be pure, then you don't care what order they're called in, because there is no interaction between them. You also know that if the same function call is made with the same arguments, that the same function return value will result from it. Those two items together can tremendously enhance the compiler's ability to optimize code without breaking things. Additionally, it enables the compile-time assertion checking and limited program proving of the typestate mechanism. (Essentially, typestate can perform as a limited form of compile-time precondition/postcondition checking).

As far as encapsulation, that is a programmer's concern, not a compiler's. A compiler's job is to make things run really fast. Breaking down encapsulation (when doing so provably won't break the code) is a great way to increase the performance of code.

Anyway, the idea of typestate is that pure boolean function calls can be used as compile-time assertions about relationships between variables and expressions. if I declare a pure boolean function, such as:

     pure boolean hasPositiveSin(double x) {return Math.sin(x) > 0; }

and I have a statement at the beginning of a different function like:

     if (!hasPositiveSin(x)) {throw new SomeKindOfException()}

or, more concisely,

     check_state hasPositiveSin(x)

at one point in the code, then since the "hasPositiveSin" function is known to be pure, a later call in the same function which checks the same condition must have the same value. Thus if I have later code such as:

     if (hasPositiveSin(x) || someOtherCondition(x,y)) { doSomething(); }

the compiler knows it can simplify this to:

     if (true || someOtherCondition(x,y)) { doSomething(); }

which can be further simplified to:

     doSomething();

and likewise if it encounters a later check_state statement that asserts something contradictory to a previous one:

    check_state !hasPositiveSin(x)

it can alert the user to a compile-time error, since the compiler can prove that if flow control went from the first check_state statement to this one, that this one will always fail.

note that the compiler never had to actually EVALUATE the hasPositiveSin(x) function at compile time. And also note that the only actual call that it inserted to it in the bytecode was in the first check_state call, because in that case it couldn't prove its value to be true or false. All of the other calls to hasPositiveSin(x) were optimized away.

Thus the user can define a set of pure boolean functions that assert a variety of useful properties about whatever items they care about (e.g. "pure boolean containsOnlyEvenNumbers(List<T> items)"). The compiler doesn't need to actually evaluate those functions at compile time -- it just needs to use the CALLS to those functions to determine if the various check_state statements are consistent with each other. In cases where it can't determine that, it inserts actual calls to the functions in a similar fashion to Java's 'assert' mechanism.

I certainly am familiar with the C# regions. This is a feature that exists purely for IDE use, and if we wanted to provide support for this in the IDE, we would be able to do so without introducing special syntax in the language. For example, NetBeans does that for Java.

We can's say sql:"...", because "a:b" means "type of a is b", but I get your point about a more concise syntax.

We will definitely have multiline strings.

Yes, you can annotate any declaration is such a way