Neat! The idea that 'types are just constraints on values that happen to be checked at compile-time' is something I've been thinking about for a long time. I've been thinking about building a Scheme-like language on the same principle.<p><pre><code> (define (my-function some-number) (assert (is-int some-number)) (assert (is-nonzero some-number)) (...body of function goes here))
</code></pre>
That way you can start with a dynamically typed language and slowly add type information (and any other constraint you want) without having to modify the syntax. A Sufficiently Advanced Compiler may be able to detect problems that e.g. `javac` wouldn't. But I'm probably repeating what the Candy devs already said in their readme.<p>The thing holding me back, aside from general indecisiveness and getting stuck in bootstrapping loops (I immediately get annoyeed with existing build tools and want to write my own...in my language that doesn't exist yet) is that I wonder if I should learn about dependent types, first, in case it totally changes my approach. I've had a PDF of The Little Typer open to some page in chapter 2 for months, now.<p>Another concept I want to embed is that there are no fundamental structural types. e.g. anything that acts like a list is a list. What you <i>really</i> want to know is the 'color'[1] of values, i.e. 'what does this value MEAN'. Because you can represent anything as a list, and especially in dynamically-typed languages, it's not always obvious if you're supposed to e.g. interporet a list as a list, or as something else, represented by the list. "You must beware of shadows", as they say. Maybe what I want is 'dynamic structural types but static coloring'.<p>[1] term borrowed from the JavaScript world, often referred to as the 'function coloring' problem, though it's not really about the function so much as the values they take and return. "Is this promise you just passed me standing for itself, or did you want me to calculate something based on the promise's result value?"