There are 2 major things in this release:
Asserts
The biggest change in this release is the addition of the assert construct. This is backwards-compatible except if you were using 'assert' as an identifier, in which case you'll have to rename it (or use quotes "assert": in the case of a field name).
Assert expressions
assert e1 : e2; e3
Is simply desugared to
if e1 then e3 else error e2
And the : e2 is optional like in Python and Java (except Python uses a comma instead of a colon).
Object assertions (invariants)
It is also possible to put asserts into objects:
local Base = {
assert self.x <= self.y : "%d greater than %d" % [self.x, self.y],
x: 1,
y: 2,
};
These are preserved over inheritance and follow the usual late binding semantics.
Base { x: 3 } // Raises an error.
Base { x: 3, y: 4 } // Ok.
This can be useful for enumerations:
local Base = {
assert std.setMember(self.animal, self.availableAnimals)
: "%s is not a valid animal" % self.animal,
animal: error "You must select an animal",
availableAnimals: ["CAT", "DOG"],
};
Base { animal: "FISH" } // Raises an error.
Base { animal: "FISH", availableAnimals+: ["FISH"] } // Ok.
If you want to constrain the base object so the animals cannot be extended, you can do:
local Base = {
local available_animals = ["CAT", "DOG"],
assert std.setMember(self.animal, available_animals)
: "%s is not a valid animal" % self.animal,
animal: error "You must select an animal",
};
Preventing override of fields
Finally, using this mechanism you can lock down a template so that users can only override the "inputs", not the "outputs". For example imagine building bash scripts as part of a workflow framework:
local Template = {
user:: error "Must set user",
command:: error "Must set command",
outputFile:: "out.log",
local template = self,
local output = {
bash: "sudo %(user)s \"%(command)s\" > %(outputFile)s" % template,
},
bash: output.bash,
assert self == output : "You may not override this template's output."
};
// User code:
Template {user: "myname", command: "ls", bash+:"; echo hi"}
This would produce an error because the assertion prevents the user from adding stuff onto the end of the bash command.
Removal of super as a construct in its own right
Early in development we decided to avoid restrictions in the language to see where this would lead us. Two such cases led to implementation complexity and we were tempted to remove them, but we were not sure if they would be useful. One case was mixins, which turned out to be enormously useful in many cases. The other case was the ability to do super by itself, not just in the context of super.f or super[e]. The semantics of this were tricky to define in the case of extending super, or extending super with itself (although we did so, and the rules are on the website)! It also makes the interpreter and object model harder to implement. To the best of our knowledge, there is not one single person using super in this fashion, so we have now restricted it to just super.f and super[e] as done in other languages.