Monday, January 19, 2009

Must have: Specialization

A must have for the language is specialization of a value to a type. A) It is a nice to have. B) It makes handling of thrown exceptions easier (in Hi any value can be thrown).

For orthogonality reasons, it would be nice if the syntax of specialization would resemble a case distinction. Or, better, if it could be handled inside a case. It must be treated differently, because, after specialization, the value gets a new type.

This seems reasonable (A):


[ i: int -> do something with i
| c: char -> do something with c
| l: list (char, a) -> do something with l ]


So, I need to be able to compile type-cases on values...

Or, a more trivial approach (B):


[ i: int -> do something with i
| c: char -> do something with c
| l: nil -> do something with l
| l: cons -> do something with l ]


Make a case distinction not on the type label but on the constructor. This is easier than the former, but probably less nice?

So, it's (A) or (B). Pro's and cons's:

+A, nice readability.
-A, hard to implement.

+B, you make a case distinction immediately, so that might also result in short code.
-B, you need access to, or expose, the structure of the type.

Question, given specialization on types, we might as well specialize on the interface? (There's no RTTI for that...)

After some thought: (A) is lousy, in the absence of a lot of RTTI you might need to visit the whole graph to derive the correct type instance (observe list (opt int)).

There is also option (C), differentiate on the type constructor:


[ i: int -> do something with i
| c: char -> do something with c
| l: list -> do something with l ]


(C) it is. Not really nice, but the best of (A) and (B).

No comments:

Post a Comment