Artyom Bologov<p>I think my idea of a simple type system for <a href="https://merveilles.town/tags/Lamber" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>Lamber</span></a> is coming together:<br>- We have primitive/nominal/tag types, like int, char, bool.<br>- We have structure/record/tuple/constructed types that consist of N types.<br>- We have function types that accept args of some type each and return a value of some type.<br>- Function types and structute types can and are recursive. They can include other types.</p><p>An important property of structure types is that their members are named by accessors (which rarely is a problem, right?) So hypothetic cons type is:</p><p>def cons = type (car cdr)<br> fn (f) f car cdr .</p><p>This way, we ensure that there are accessor functions, car and cdr, and that they return properly typed values. E.g., we can infer that for "let x = cons 1 true", "car x" will return an int, while "cdr x" will return a bool.</p><p>I've done it this way because I want a syntactically simple type system that works. A property I want to retain is never having to declare function types explicitly, only relying on type annotations/constructors inside of them to infer the types.</p><p>I'm still thinking on whether this is a good solution, but it seems to strike a perfect balance between conceptual simplicity and the amount of implementation magic required for it.</p><p><a href="https://merveilles.town/tags/theWorkshop" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#<span>theWorkshop</span></a></p>