ShalokShalom/second-layer-type-system.md

## second-layer-type-system.md

      
    Raw
  

              second-layer-type-system.md
            
          
    Hi there 🤗
While watching this talk by Rich Hickey suddenly I reminded an idea of how to increase our type safety and traceability.
I call it the second step in type systems since it offers individual types on the surface while still preserving the performance of the built-in types that the type checker already inferences in compiled and already written code.
Motivation

I suggest the idea of a type system which informs us about the specific type of an object, function or what not.

This includes everything that already has a built-in type since those are more performant while less declarative.
So this simply offers specific information in the form of custom type inference that associates each item as an own type.

I call it the individual type deduction. This helps to understand the code flow and also increases the type safety.
You completely avoid confusing different types of strings, integers, floating point numbers and that like. 🤗

And you get some clean and obvious insights when you look into the type flow declaration.
I always thought that primitive types contradict the sense of a type system.
In order to add two strings together, you could simply declare as one type in the type annotation.
Custom types prevent us from confusing different strings while significantly increasing the traceability.
The only benefit of using built-in types is performance. Why not make it clear to us in order to compile it efficiently then?
This is also shown by Rich Hickey in the talk above and the reason why I write you that RFC here.

This second layer is of course just visible to the humans and gets ditched into the void at compile time.
Honestly, I have very less experience in coding and it might be the case that there is obviously a blunt reason why this is not implemented yet in any language I have ever seen.
I currently see zero downsides on this, do you?
It might be that I am possibly crucially confused on the simplicity of this approach and this is potentially significantly more challenging to implement as it happens to appear on the surface. This would not be the first time 😉
It might be on the other side, that this is one of the cases where the whole industry did something for a couple of decades, which turned out to be extensible by something simple and efficient. And that would also not be the first time.
Before

const y = "test" # string type
After

I suggest adding a second layer on top of it.
const y = "test" # test type before, and string type while the compilation. 
This is, as said, only visible to the human and never gets actually compiled.
So, the performant build-in types simply get elegantly combined with individual types who happen to say precisely, secure and clear what we are working on.
Thanks a lot for all your efforts and reading this idea. 😇