How to compile if expressions? Maybe do not allow them to be nested inside stuff? Only assigned to variable or as return value?
Currently, I do AST generation manually by traversing the CST and generating AST nodes. This could be improved
significantly. One option is to create an extension to tree-sitter that produces much higher quality bindings.
A sketch of the idea is to map tree-sitter rules to Rust data structures. For instance, seq
could be a tuple,
repeat
could be a Vec
, token
could become a unit struct, choice
is an enum, a rule becomes a struct, etc.
As an example:
{
letDeclaration: $ => seq(token("let"), $.name, token("="), $.expression)
}
struct LetDeclaration(LetToken(), Name, EqualsToken(), Expression);
Or even with fields:
{
letDeclaration: $ => seq(field("let_token", token("let")), field("name", $.name), field("equals_token", token("=")), field("rhs", $.expression))
}
struct LetDeclaration {
let_token: LetToken(),
name: Name,
equals_token: EqualsToken(),
rhs: Expression
}
This might require some rules on tree-sitter grammars such as choice
must always be top level
(although anonymous structs is a reasonable solution)
Currently, tree-sitter compiles to WebAssembly via a custom build script. I'd like to change that, so it can be compiled via the Rust build.rs script. That way it can be used with the rest of a Rust codebase that is compiled to WebAssembly.
The current idea is to fix up the build.rs script. However, a longer term idea is to just compile tree-sitter grammars to Rust instead of C.
The basic types in Vicuna are i32
, f32
, bool
, string
.
We have structs:
struct Foo {
a: i32,
b: i32
}
and enums:
enum Bar {
A(i32),
B {
baz: string
}
}
There are traits:
trait Foo {
fn bar() -> i32;
}
impl Foo for i32 {
fn bar() -> i32 {
42
}
}
- Add nested pattern matching
- Add completeness checking for pattern matching
Add tuple enum variantsAdd empty enum variants- Add ranges (1..2 or 1.to(2))
- Add closures and iterators
- Error handling
- Figure out modules and standard library
- Maybe add a way to call JS?
- Add type checker output printing/playground
- Fix ambiguity around end expressions and expression statements
Figure out how tuple enums work (should we bite the bullet and use type checker information?)Or define functions that produce an enum representation?- Ended up defining functions
Have a single struct rule that can take either one identifier or two identifiers separated by ::
.
In the symbol table we index by the full name, i.e. Foo::Bar
or Bar
. Somewhere we have to
store the other variants in an enum.
Do we want to encode this in the Type
type? Because right now we just say it's a named type,
which doesn't give any sort of info about the type itself, and is more a syntactic
representation. Perhaps it should be a more sophisticated struct/enum type with type
substitutions.