Hard choices, r6rs, harder to write code ¶

I have made some important changes on the master branch of Vicare. These changes will make some fully compatible r6rs code not to compile anymore or raise run–time errors. Life is hard. It goes like this:

• r6rs is the base of the language implemented by Vicare, but full compatibility is of no real value for the project. There is no big code base that relies on Vicare’s compatibility (putting aside the code I write). I think I can port the most interesting of the existing libraries to the typed language.
• The typed language allows to catch more errors at expand–time at the simple cost of specifying the type annotation of some syntactic bindings. The typed language offers more features and it allows the generation of faster code.
• I have decided that developing and using the typed language is more important than maintaining full compatibility with r6rs.

So, r6rs informs us that some expressions, under some conditions, return unspecified values. This is bad. In many such situations: Vicare caused the expressions to return the single value ‘#<void>’, which is bad for obvious reasons. I have made changes so that in such situations the expressions should return zero values; we can return zero values with (values). This has hard consequences especially with conditional expressions.

Here is what happens:

• When an expression is a syntax use of when: the expression always returns zero values.
• When an expression is a syntax use of unless: the expression always returns zero values.
• When an expression is a one–armed syntax use of if: the expression always returns zero values.
• When an expression is a two–armed syntax use of if: the arms must return the same number of values; it does not matter which types the returned values have, but the number of values must be the same.
• When an expression is a syntax use of cond without else clause: the expression always returns zero values.
• When an expression is a syntax use of cond with else clause: the branches must return the same number of values; it does not matter which types the returned values have, but the number of values must be the same.
• When an expression is a syntax use of case without else clause: the expression always returns zero values.
• When an expression is a syntax use of case with else clause: the branches must return the same number of values; it does not matter which types the returned values have, but the number of values must be the same.

Notice that raising an exception in a clause will match any number of values from other clauses, so the following will compile correctly:

(if (test-expr)
    (values 2 3)
  (error #f "error"))

Clearly these changes make writing code harder. We have to care about the return values. We have to care about the else clause. Using the typed language helps in finding and fixing a mismatch in returned values; when using the standard language we are left on our own with “your problem” run–time error messages.

To mark this step: I have bumped the version number from “development 0” (0.4d0) to “development 1” (0.4d1).