WhileyCompiler
WhileyCompiler copied to clipboard
Whiley
The Whiley Compiler (WyC)
_(see also #955 and #882)_ At the moment, the following currently passes type checking: ```Whiley function count(int n) -> (int r): int|null i = 0 // while i < n:...
At the moment, type refinement via assignment is permitted. This is a useful feature which, for example, allows the following to compile: ```Whiley int|null x = 1 int y =...
There is currently a problem with a type such as the following: ```Whiley public type ExposedSquare is { bool holdsBomb, int rank } where rank >= 0 && rank ExposedSquare...
_(see also #985)_ Currently, the following is not supported: ```Whiley &(int[]) p = new [1,2,3] (*p)[0] = 2 ``` The problem is that is claims we `cannot dereference dynamically sized...
There are currently some problems related to the way that binding occurs against union types. The following illustrates: ```Whiley function select(S|T x, S y) -> (S|T r): if x ==...
The following produces a `StackOverflowError`: ```Whiley type List is { null|List next } function damn(T x) -> List: return {next: damn(x)} ```` That's not ideal! Thanks to @IsaacOscar for pointing...
The following fails because of flow typing: ```Whiley function create(nat size, nat value) -> nat[]: int[] r = [0; size] nat i = 0 while i < |r| where r...
Despite the considerable progress made on improving type inference in Whiley using a bidirectional algorithm, there remain some problematic cases. Consider this: ```Whiley function select(T x, T y, bool f)...
Currently, the compiler rejects things like this: ```Whiley List items = ... ``` The compiler is recognising `>>` as the right shift operator! This is an age-old problem first encountered...
There seems to be a problem parsing lambda accesses like so: ```Whiley return { ..., // Action Processor (dummy) process: &io::processor } ``` There are two essential issues. Firstly, we...