Implementing the language I& #39;m designing is hard. A thread!
So my language is very flexible and generic. Generic like C++? Well, yes, but actually no.
My language allows for great compile-time control. But this proves hard to implement.
Allow me to explain with examples.
1/9
So my language is very flexible and generic. Generic like C++? Well, yes, but actually no.
My language allows for great compile-time control. But this proves hard to implement.
Allow me to explain with examples.
1/9
A simple program:
def (get_s8) :: [] -> type = s8;
This is a function that returns a type. Yes, that works. Yes, it& #39;s possible.
(def (= (: (get_s8), (fn [], type)), { s8 }));
This is one of a couple of intermediate representations (later called ir) of my language.
2/9
def (get_s8) :: [] -> type = s8;
This is a function that returns a type. Yes, that works. Yes, it& #39;s possible.
(def (= (: (get_s8), (fn [], type)), { s8 }));
This is one of a couple of intermediate representations (later called ir) of my language.
2/9
The : is roughly equivalent to ::, and fn is roughly equivalent to ->.
Now this poses a problem. To be truly flexible and generic, fn needs to be a compile-time function. But the ir I presented is already a compile-time program! So really, we need to recurse.
3/9
Now this poses a problem. To be truly flexible and generic, fn needs to be a compile-time function. But the ir I presented is already a compile-time program! So really, we need to recurse.
3/9
(let (= (: $0, type), (esc_type_function0 type)));
(format-ast
(def (= (: (get_s8), (replace $0)), { s8 }));
This is another, deeper, ir, that jit-compiles to a program that generates an ast. I& #39;ll give you a second to let that sink in.
4/9
(format-ast
(def (= (: (get_s8), (replace $0)), { s8 }));
This is another, deeper, ir, that jit-compiles to a program that generates an ast. I& #39;ll give you a second to let that sink in.
4/9
In the last program esc_type_function0 is a function implemented by the compiler, it creates a new function type with no parameters and a return type. Some basic set of builtins is simply necessary, this is one of those. So now that we finished recursion, we can walk back up.
5/9
5/9
We now have a usable definition of this, since we now know what the value of (fn [], type) is.
(def (= (: (get_s8), (fn [], type)), { s8 }));
This means we can now jit-compile this program and use the get_s8 definition however we want.
6/9
(def (= (: (get_s8), (fn [], type)), { s8 }));
This means we can now jit-compile this program and use the get_s8 definition however we want.
6/9
The point of this thread is to show the theoretically infinite flexibility of the type system of the language I& #39;m designing.
Now you may ask yourself, is this approach even optimal? Surely it has to be extremely slow.
7/9
Now you may ask yourself, is this approach even optimal? Surely it has to be extremely slow.
7/9
This is the point of my experimental compiler — exploring techniques to make this not just extremely useful, but also exploring optimizations that would make this approach as fast as your regular modern compiler (or even faster?)
8/9
8/9
Now what about code speed? To be honest, I don& #39;t see a reason why this code should be slower than C code — assuming the same optimizations are applied as in gcc or clang. Because all of this happens at compile time, runtime should not be affected in any way by this.
9/9
9/9