Maybe vs. exception vs. failure thunk in Scheme

It's pretty easy to switch back and forth between representing a function with a "maybe" result type as:

1. returning X or #f;
2. returning X or raising an exception; or
3. returning X and taking a failure thunk

In Scheme, sometimes X might include the value #f. In that case I think representation #3 is the best one, since raising an exception is clunky. You can also combine #2 and #3 and take an optional thunk that by default raises an exception.

This is one case where true unions do cause some problems, so maybe I should have tempered my earlier enthusiasm a little. Still, it's not insurmountable, and this cost needs to be weighed against the price of strictly disjoint unions.

True unions, revisited

I've spoken about true unions (or ad-hoc unions, or non-disjoint unions) sort of abstractly before, but Typed Scheme has 'em, and they're great.

In my recent experiences with Haskell and ML, the amount of unnecessary and distracting injection and projection that goes on starts to bloat code to the point of illegibility. Disjoint unions in ML and Haskell provide two orthogonal pieces of functionality in one feature. Typed Scheme separates these two: struct types give you disjointness, and unions give you, well, unions. It's up to you to guarantee that you don't create unions with overlap, but so far I haven't seen that cause any problems.

Then you can build disjoint unions on top of that, as I have in my new types.plt PLaneT package:

(define-datatype Expr
 [Var ([name : Symbol])]
 [Abs ([var : Symbol] [body : Expr])]
 [App ([rator : Expr] [rand : Expr])])

macro-expands to:

(begin
 (define-struct: Var ([name : Symbol]))
 (define-struct: Abs ([var : Symbol] [body : Expr]))
 (define-struct: App ([rator : Expr] [rand : Expr]))
 (define-type-alias Expr (U Var Abs App)))