natefaubion/example-functional-compiler

example-functional-compiler's Issues

modular components

Since you have a common intermediate compilation language of system f, it would be really nice if you had a way of stringing your stages together with something like pipes package so that it would be easy to use your modules with differing compilation targets.

Interoperability seems to be severely lacking in most compiler designs.

language server

Did you consider a language server? It seems like language servers are a major advantage that new development environments can utilize now.

README Print Section

The Print section does not state what it actually does.

Does it print documentation, target language like JavaScript/assembly?

Arbitrary Point of Entry Compilation

https://www.youtube.com/watch?v=wSdV1M7n4gQ was very inspiring with how the language server starts compilation at the point of editing changes.

Is this something that you would consider?

lazy compilation for JIT

It seems like lazy compilation would be advantageous for a repl or quick interpretation to quickly rerun a modified code without waiting for compilation.

reverse AST to source

In the Parsing you stated “This means our original source is fully represented in this tree, and can be printed back out exactly.”

How do you get this to print back to source? I see no implementation for that.

Would you consider a biparsing solution similar to the one outlined in https://github.com/BebeSparkelSparkel/biparsing/blob/master/papers/1902.06950.pdf ?

data structure to define language

Maybe this has been tried before but have you considered defining you language syntax as a data structure in a common format like json, yaml, dhall so that there can be a common reference for generating a parser for the multiple implementations of the parser.

This would allow parsers to be generated from the defined syntax so that there could be:

• all parser implementation would remain up to date without as much maintenance since they generate the parser instead of having a static implementation of the parser that needs to be
• clear changes to the actual language syntax in the version diffs not just the parser implementation
• This makes it a dynamic language that is self modifying and allows for module, function, line level language extensions/contractions
• less software rot because the code can specify which language version it is using and on the fly generate parsers for that version

Questions:

• What should the data structure actually define? syntax to ast, syntax to lexer to ast
• Should it define the progression of steps from syntax to lexed tokens to ast to system f? I don't like this solution because it constrains the modularity. Perhaps they could be separate definition files. Anyways, better suggestions would be appreciated.