Typed Compiler IR?

[gnumonik]

Related to #6:

The existing PS compiler pipeline does not produce a suitable IR for conversion into a typed language, which is a problem if we target PIR or TPLC (or perhaps even if we target UPLC but want to perform optimizations that require type information).

The PS compiler performs typechecking and type inference on the Language.PureScript.AST (the "AST AST") AST, not on the Language.PureScript.CoreFn (the "CoreFn AST") AST. There exists machiner to convert AST AST -> CoreFn AST, but not the other way around. (I'm not certain that it is possible to write the conversion the other way.)

The AST AST, however, is not suitable for either PIR or TPLC codegen: The AST AST is a "sugared" AST which matches much more closely the PS source module written by a user of the language. The CoreFn AST, by contrast, is a desugared AST which matches the structure of PIR and TPLC quite closely - but, as constructed by the PS compiler, the CoreFn AST lacks type annotations.

Roughly, the relevant portions of the compiler pipeline, in order, are:

• "Desugars" the AST AST (this doesn't yield a suitable CoreFn representation but a simplified AST representation)
• Typechecks the desugared AST
• Regroups module bindings (this is important but I haven't looked into the details of how it works)
• Converts the regrouped module to a CoreFn AST
• Performs codegen on the CoreFn AST

The CoreFn AST could be annotated with type information, using the type parameter. Usually this is a CoreFn.Ann.Ann, but (SourceType,CoreFn.Ann.Ann) would work for our purposes. Just for the sake of simplicity, let's say that

type TypedCoreFnExpr = CoreFn.Expr (SourceType,Ann)

The problem for us, however, is that we need to convert to CoreFn AND Check/Infer types at the same time to end up with a Typed CoreFn AST. (Strictly, I guess we only need to infer types, we can check beforehand.) This means that we need to mash together the CoreFn.Desugar module and the Language.PureScript.TypeChecker.Types infer function to arrive at a typed CoreFn AST.

Note that we can't just call infer with the Env that we get as a result of typechecking the AST AST - we need to infer the type of everything, not just the top-level types in a binding group, which means we have to interact with the typechecker state to (e.g.) bind lambda argument and introduce their names/types into a local scope.

Solving this problem invariably required modifying the compilation pipeline. However, I think there's a good chance we could upstream our changes: If PureScript really wants to provide a language-agnostic frontend, then they should be open to a more robustly annotated CoreFn AST.

[gnumonik]

I have a really rough Typed CoreFn branch here. Only way I could think of to figure out whether we could easily get this without too much disruption to the PS compiler was to try to do it. Doesn't seem that bad.

[klntsky]

This is impressive!

What do you think should be the interface for the "linker"? In terms of haskell function types

[klntsky]

I think there's a good chance we could upstream our changes: If PureScript really wants to provide a language-agnostic frontend, then they should be open to a more robustly annotated CoreFn AST.

I don't think they will accept it - I clearly see that it is done like this on purpose. There is no need to keep the type information, therefore, it is discarded during typechecking.

If PureScript really wants to provide a language-agnostic frontend

AFAIK nothing indicates that this is the goal.