# Letlang — Roadblocks and how to overcome them

--

# Introduction

I’ve been working on and off on my own programming language, Letlang, for a while now. You may have already read a bit about it in my previous articles.

I have made a lot of progress on the design of the runtime, and the features I want.

But we’re still nowhere near something “stable”. I met some roadblocks which makes me rethink the semantics and the syntax as a consequence.

In my opinion, the syntax needs to reflect clearly the semantics of the language. The syntax is “derived” from the semantics.

In this article, I’ll expose some of the roadblocks I’ve met and what solution I have thought of.

# Quick Recap: The type system

The type system of Letlang is dynamic and enforced at runtime. This is because of the very nature of what a “type” is in Letlang.

For a quick reminder: Values do not have a type, instead they belong to a collection, called a “class” (inspired from proper classes in set theory). The class defines the constraints a value must respect to be considered “part of the class”.

The example I like to give is with the classes `even`

and `odd`

:

`even`

: all integers`n`

such as`n % 2 = 0`

`odd`

: all integers`n`

such as`n is not even`

In the runtime, classes are modelled as functions that takes a value and returns a boolean indicating whether or not it belongs to the type.

This model prevents static type checking. When checking types during compile-time, I need to be able to verify the “compatibility” between types, consider the following classes:

`mod2`

: all integers`n`

such as`n % 2 = 0`

`mod3`

: all integers`n`

such as`n % 3 = 0`

`mod4`

: all integers`n`

such as`n % 4 = 0`

Here, we can say that all members of `mod4`

are also members of `mod2`

. But we can’t say the same for `mod3`

. This means:

`mod4`

is compatible with`mod2`

`mod3`

is not compatible with`mod2`

`mod2`

is not compatible with`mod4`

(not all multiples of 2 are multiples of 4)