Holes: ideas and puzzles

[note that holes have been brought in to version 0.0.4 of the doc, but in a simpler way than this.]

An example from the overview:

firstCase someExpresion of [
{ `x, ok = $; … }
{ `x, error(timeout,`extraInfo) = $; … }
{ `x, `otherError = $; … }]

The idea is that when the error is a timeout we extract the extraInfo and do something with that. The error identifier is acting as a procedure here, and maybe it is one, just building up an appropriate structure:

`error = { (`errorCode,`extraInfo) = $; (.error, errorCode, extraInfo) }

Here we return a 3-tuple with an atom first component used to identify it as an error structure. This might not be a very likely methodology, but it is conveniently illustrative.

`extraInfo is a hole waiting to be filled. What can we make of it being a part of the parameter we pass to error? And holes naturally appear in other places (such as pigworker’s amazing derivatives of data structures). And we’ll see others below. We want to handle them in a uniform way.

The easy thing, if we can make it work, is to see holes as just another type. Let’s write -T for a hole of type T. If X convertsTo Y, then we see that -Y convertsTo -X. If Int convertsTo Rational, then a hole for a Rational can take an Int. We want this to also work for the more important isA relation, and let’s assume that before getting to how it might work.

Extrapolating wildly based on our notation, it is natural to assume that Empty = -Empty, and the other hole types are below that, with -Any at the bottom.

An interesting thing happens when you consider the type Assignable(X) of mutables that can hold a value of type X. Naturally Assignable(X) convertsTo X, so that we can conveniently use the value. But now we see that we can also have Assignable(X) convertsTo -X, which will allow us to use our Assignable as a hole and assign new values using more general hole-oriented code.

The isA rule is that properties must always decrease as we go up. To fit this in we will say that holes types have negative properties. Some types (such as Assignables, or the tuples we looked at above) have mixed positive and negative character. The isA rule now says that, as we go up the isA hierarchy the number of positive properties must go down, while the number of negative properties must go up.

I’m not sure if this is all going to work, but it is fun.

[update: This suggests that an explicit closure should be an Any=>-Any, and maybe other things.]

[upupdate: A cute thing, if this all works is the ancient assignment statement becomes:
someHole := someExpression
and this works in all hole contexts, and its use for Assignables becomes a special case.]