PHP Warning: call_user_func_array() expects parameter 1 to be a valid callback, no array or string given in /am/paramount/vol/ecs/sites/whiley/wp-includes/class-wp-hook.php on line 298


  • No categories

Whiley v0.2.8 Released!

Here is the latest update for the Whiley-to-Java Compiler.  It now weighs in at around 47KLOC, spread over 272 classes.  There are 379+ distinct test inputs, which give rise to around 615 actual JUnit tests.  Anyway, the list of improvements includes:

  • Fixed numerous outstanding bugs
  • Improved reporting of syntax errors
  • Added list append
  • Added support for recursive types
  • Added the type matching operator ~=
  • Modified syntax of define.  Instead of “define type where cond as name”, it’s now “define name as type where cond”
  • Small updates to standard library
  • Redesigned the way Wyone handles types to enable better translation of Whiley’s union types

Overall, it’s looking a lot better.  However, it still won’t compile anything that’s really non-trivial and there are several outstanding design flaws that need to be figured out.  These include:

  • The way constrained recursive types are handled is insufficient.  The problem is that recursive types are handled using a recursive type constructor (e.g. X[int | (X left, X right)]) , but there is no equivalent for the constraints.  One possible solution here is a closer coupling between the type itself and the constraints imposed upon it.
  • The way type tests are implemented does not work well with type inference.  Type inference is used to prevent the need for a cast operator in Whiley.  The problem is when you perform a type test on something which is not a variable, then we cannot update the environment to reflect this.  One possible solution here is to introduce a simplified intermediate representation which uses a 3 address code.  This would then mean complex expressions where broken down into simpler ones which were connected via conditional branching.
  • The way boolean values are represented in the automated theorem prover, wyone, does not work well.  Wyone currently follows a classical approach where we things which return boolean values have a special status.  For example, a predicate is a special kind of function which returns a boolean.  The disadvantage of this is that it makes things rather unsymetric, and is responsible for a number of outstanding bugs.  A more unified, albeit less classical, approach would considerably simplify things.

Right, that’s all fow now — enjoy!

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>