[<<][staapl][>>][..]

Mon Oct 12 18:34:24 CEST 2009

Staapl in ML?

The problem is that an untyped approach allows for several ``higher
order'' tricks that are more difficult to do in a strict type system.
I.e. the assembler is implemented as something akin to am algebraic
data type, but it is still possible to also match the opcode
parametrically (which would be a constructor in a straightforward
implementation in ML).

I wonder, is this good or bad?  It's good that I can express more, and
manually add some constraints at compile time, but it's bad that some
corner cases escape this ad-hoc type system.

[Reply][About]

[<<][staapl][>>][..]