Our evaluation semantics up to this moment has been what is known as call-by-name. Which means that when evaluating a function call f(x), x gets replaced inside f's body and then the body is evaluated.
This has some cool advantages, like not evaluating unused values:
fn foo(x: Int, y: Bool) do
if y do x else 0 end
end
foo(slow_computation(), false)
There slow_computation() won't be evaluated at all becase y is replaced by false and the do branch of the conditional never gets evaluated.
However, this evaluation strategy also limits our backend choices. All the code generators I know (LLVM, cranelift) are better suited to do regular call-by-value or eager evaluation. Which means that to evaluate f(x), first x is evaluated, and the resulting value is used inside fs body.
There have been some effort in doing lazy evaluation using LLVM but it seems there is a lot of things to do/learn before getting to that point.
This does not mean we have to drop the idea of doing lazy evaluation, we can keep our current backend (the lir and machine modules) and keep it up to date with all the changes done to the rest language.
What I propose is that we introduce a new IR (like #77 but without the lazy evaluation part) and a code generator module such that we are able to use LLVM or Cranelift to compile our programs.
Our evaluation semantics up to this moment has been what is known as call-by-name. Which means that when evaluating a function call
f(x)
,x
gets replaced insidef
's body and then the body is evaluated.This has some cool advantages, like not evaluating unused values:
There
slow_computation()
won't be evaluated at all becasey
is replaced byfalse
and thedo
branch of the conditional never gets evaluated.However, this evaluation strategy also limits our backend choices. All the code generators I know (
LLVM
,cranelift
) are better suited to do regular call-by-value or eager evaluation. Which means that to evaluatef(x)
, firstx
is evaluated, and the resulting value is used insidef
s body.There have been some effort in doing lazy evaluation using LLVM but it seems there is a lot of things to do/learn before getting to that point.
This does not mean we have to drop the idea of doing lazy evaluation, we can keep our current backend (the
lir
andmachine
modules) and keep it up to date with all the changes done to the rest language.What I propose is that we introduce a new IR (like #77 but without the lazy evaluation part) and a code generator module such that we are able to use LLVM or Cranelift to compile our programs.
cc @DarkDrek @seanchen1991