Skip to content
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

Closed
johnynek opened this issue Sep 30, 2018 · 8 comments
Closed

implement fully typed AST format #54

johnynek opened this issue Sep 30, 2018 · 8 comments

Comments

@johnynek
Copy link
Owner

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

@johnynek
Copy link
Owner Author

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.

@johnynek
Copy link
Owner Author

johnynek commented Mar 8, 2019

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.

@avibryant
Copy link
Collaborator

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.)

@johnynek
Copy link
Owner Author

johnynek commented Mar 8, 2019

Well I want some ability to write the ASTs, so I have to choose some format. I have considered three possibilities:

  1. Protobuf. Also portable, but humans can’t cat it out to inspect easily, which is at least a minor downside.
  2. JSON. Humans can print it, and others can read it programmatically, but the lack of schema may make it still a lot of work to consume in a program.
  3. A lisp like text encoding. Possibly less verbose than a JSON encoding, probably only slightly more work to parse for an experienced parser writer.

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...

@johnynek
Copy link
Owner Author

johnynek commented Mar 8, 2019

What do you think Avi? I’d welcome any critique or suggestions.

@avibryant
Copy link
Collaborator

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 cat.

@johnynek
Copy link
Owner Author

sold. I'll use protobuf when I take a stab at this.

@johnynek
Copy link
Owner Author

This is done!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants