Types

Published on Saturday, June 24th, 2017


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.

<3 jzp