-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
implement fully typed AST format #54
Comments
Note: the fully typed AST allows us to have other tools that consume bosatsu output without having to parse significant whitespace nor having to deal with type inference. We should include the original filename and source locations of in the resulting AST in case we need to show errors. |
circe keeps the order that keys are added in objects. That should make the output fully deterministic, so there should be no reason not to use circe for serde of the JSON. I think JSON is a good choice for interoperating with others that might want to produce or consume the typed ASTs and APIs. |
Is the idea behind using JSON that there might be compilers that are not written in Scala? (That seems like a far off possibility to me but maybe you have something specific in mind.) |
Well I want some ability to write the ASTs, so I have to choose some format. I have considered three possibilities:
I can imagine writing a compiler for language X in that language and use the scala front end as a parser and typechecker. I don’t think anyone would ever want to reimplement that. But you might make a rust backend in rust, etc... |
What do you think Avi? I’d welcome any critique or suggestions. |
I would vote for protobuf: I think the presence of a schema - especially as a canonical, language agnostic form of documentation - trumps the minor inconvenience of not being able to use |
sold. I'll use protobuf when I take a stab at this. |
This is done! |
similar to #8 we should be able to emit a fully typed AST that is reasonably easy to parse. The goal here is to make compilers easy to implement since we can fully separate type inference from code generation.
Implementation of evaluators is also much improved if we can fully know the types.
At least getting the internal representation for this seems high priority to finish the adoption of the rankn type inference #5
The text was updated successfully, but these errors were encountered: