So, I've been a-thinkin'... I want Elsa to be a strongly typed language, meaning that implicit casting/coercion is verboten. I think it's more of a trap than it is a help, especially in languages that rely heavily on functional composition. (So unless the programs are typically tiny, I feel that implicit casting/coercion should be relegated to the same scrapheap as DWIM and automatic semi-colon insertion. But I digress.) That said, I am a firm believer in duck-typing, and that the focus on what a type is should be defined on what you can do with it. I also feel that types should not become minutiae that encumber the programmer when it is not needed. In other words, I want to be able to define types that are based around traits and keep type declarations optional when it makes little sense in having them around. What is a trait, then? Well, a type is basically just a label that can be attached to a value. It says nothing about what can be done to the value by itself. However, functions that specify types in their parameter lists add to the body of traits that a specifc type can have. (It's sort of like how generic functions, methods and classes are intertwined in CLOS.) Primitive types and the operations that can be made on them form a set of axioms from which derived types can be made. I'm not sure if this is a good idea or not, or if it makes a lick of sense, but that's kind of the point with this little project of mine. To find out. :) [Edit 2017-07-14] Apparently what I'm talking about is a form of structural type system that leans towards duck typing.