proj-oot-old-150618-ootTypeThoughts

'vague types': e.g. 'real number' or 'date' or 'time delta'. These are things that in theory have a precise definition but cannot be or cannot be efficiently represented, and in addition may (or may not, in the case of 'real number') have different units.

in order to make it into a normal CS type, you may need to add a unit, and you need to add a representation (how it is represented in bits in memory, and how the encapsulated operations can be performed on those), and in addition, you may need to change the semantics to deal with implementation issues, e.g. for real numbers you need to limit precision somehow (not always in a fixed way, e.g. IEEE 754 floating point), and you also need to limit range somehow (e.g. CS floating points and ints have a max and a min), and maybe you need to specify behavior for dealing with these things (e.g. if you are at the max and you add 1, does it wrap around? if you add a too-tiny value, does nothing happen?) And maybe you need to specify things like NaNs?, too.

note that with this conception, even various abstract perfect types can be reconceptualized as implementations of other abstract perfect types, e.g. ints are like an imprecise implementaion of floats, and finite fields are like a way of handing overflow in ints. This means there are embeddings between them, e.g. 0 == 0.0

---

perhaps there is a place for hoon's odors vs. structural types in oot

---

current proposal to prevent black magic like the Haskell variadic function example (http://stackoverflow.com/questions/3467279/how-to-create-a-polyvariadic-haskell-function ; see ootTypeNotes1):

just ban output ad-hoc polymorphism altogether and use type parameters for things like 'default'?

---

how to make types simple? note that:

(a) they are structural patterns/gregexs, (b) they are graphs themselves (eg. a -> (b -> c) clearly has a graph shape)

---