Simon Peyton Jones

What I'd like to do is to say, okay, so if all else fails, then at least you can, as it were, pair up a value with its type representation.

There's one reason we don't want to interpret an integer as a double-position float, for example, is that they don't even have the same representation, which is just nonsense.

One possible way, which untyped languages let you do, is to tag every integer in every double-position float with the fact, I'm an integer, I'm a double-position float.

That has a lot of overhead.

So one merit, I think it's not the biggest single merit, it is a major merit of static type systems, is you have no tags.

You know that if it says it's an integer, it's going to be an integer.

You know that if it's a double precision float, it's going to be double precision float.

But if you're not sure, maybe we could make a way to make a pair of a type representation and this value.

The type representation is now like a runtime tag.

It's like a little runtime data structure that describes the type.

And then in your program, you could say, now I want to say, oh, I've got this type dynamic.

We'll call this pair a value of type dynamic.

Now, when I want to take a value of type dynamic and treat it as a character, I want to say, oh, look, look at the type dynamic.

See if it says it's a character.

If it is, return the character.

If not, crash.

Like runtime failure.

That's fine.

You can do that.

And Haskell has good support for dynamic typing where necessary.