feat: add recursion support

[polvalente]

The main functionality addition here is enabling the type checker to not hang upon recursions.

This was done by adding a Loop type which can then be used to properly warn the user about the recursion.

Support for inter-module loops still needs to be verified. In theory, this PR already supports it, but I found no easy way for testing this.

Also, I ended up adding a minor fix to the public_function_def combinator so it supports empty functions.

[polvalente]

There are still tests that need to be written for this. I mostly added it because I wanted to see if the module_compiler_test.exs suite would pass with the get_type refactor

[polvalente]

Instead of mapping {f, g}, ideally we should keep track of all the indirect dependencies so we can handle cases like a -> b -> c -> a

A data structure like the one below would solve this.

%{a: MapSet([b, c]), b: MapSet([c, a]), c: MapSet([b, a]}

[polvalente]

@emilsoman I tried removing this, but to keep my Nothing test, I'll have to either introduce a Nothing literal or accept uppercase letters in atoms.

For now, I managed to introduce this lovely piece of code to force things

[polvalente]

This also shows that it may be better to accept :"<content>" syntax and also to support the same charsets as Elixir and Erlang support for atoms

[emilsoman]

😄 haha i understand the pain here. We can support :"string" in the future

[polvalente]

@emilsoman I had to roll this back because some tests were hanging. I've added this comment to make it clear why we take this approach

[emilsoman]

Sure, we can just say the tests were hanging and which ones as part of the comment to make it clearer

[polvalente]

@emilsoman I ended up keeping this as a separate submodule because in this way we can use the same graph logic for handling loops in the sequential type checker version!

In that case, we initialize a separate graph which reference is propagated upwards in the callstack. I'll point the relevant pieces of code in the TypeChecker module

[polvalente]

Whenever we start the callstack, we don't have the :callstack set, so we need to create a new dependency graph.
In a future refactor, we can use Env structs instead of plain maps, and force envs to have new graph by default.

Also, the first call in the stack will have :latest_called_function unset, so we currently check this to avoid touching an unset graph

[polvalente]

For each subsequent call in the stack, we have both the mfa for the last called function and for the current one. This implies that :latest_called_function depends on mfa, so we can set this on the graph

[emilsoman]

@polvalente I was spending some time on this the past few days and I think we should first define our expected behaviour. The following should type check successfully:

    fn a : Loop(Int | String) do
      if true do
        b()
      else
        123
      end
    end

    fn b : Loop(Int | String) do
      if true do
        c()
      else
        "abc"
      end
    end

    fn c : Loop(Int | String) do
      a()
    end

    fn d : Int | String do
      a()
    end

Also, note regarding functions with effects: currently if there's a function with a side effect, it's return type will be Effect(<some time>). If this function is recursive, it will be Loop(Effect(<some type>)). Here "Loop" and "Effect" are flags that indicate that the function is recursive and it has a side effect. This means Loop(Effect(<type>)) and Effect(Loop(<type>)) should be treated the same. While this is okay to get started with, I'm wondering if we should introduce some form of "flag" in the type signature, something like fn my_function(x: Int) : Int !effect !loop or fn my_function(x: Int) -[loop, effect]-> Intetc. Do you have any ideas for this?

[polvalente]

@polvalente I was spending some time on this the past few days and I think we should first define our expected behaviour. The following should type check successfully:

    fn a : Loop(Int | String) do
      if true do
        b()
      else
        123
      end
    end

    fn b : Loop(Int | String) do
      if true do
        c()
      else
        "abc"
      end
    end

    fn c : Loop(Int | String) do
      a()
    end

    fn d : Int | String do
      a()
    end

Alright! I'll try to get this to work next week. Feel free to make your own attempts if you like, just let me know!

Also, note regarding functions with effects: currently if there's a function with a side effect, it's return type will be Effect(<some time>). If this function is recursive, it will be Loop(Effect(<some type>)). Here "Loop" and "Effect" are flags that indicate that the function is recursive and it has a side effect. This means Loop(Effect(<type>)) and Effect(Loop(<type>)) should be treated the same. While this is okay to get started with, I'm wondering if we should introduce some form of "flag" in the type signature, something like fn my_function(x: Int) : Int !effect !loop or fn my_function(x: Int) -[loop, effect]-> Intetc. Do you have any ideas for this?

I think that for this first iteration it's ok to return Loop(Effect(<type>)). However, it does seem nicer having function annotation flags instead of a a type wrapper, and even more so since they don't have precedence over each other (and even if we introduce ones that have, this can be documented outside of the annotations, just like operator precedence)

[polvalente]

Closed in favor of #87