Rethink AST API while considering syn

[Kampfkarren]

syn, an established syntax tree library for Rust, has things like Punctuated and whatnot. Would be smart to look through what syn does and see how much of it full-moon should have.

[Kampfkarren]

syn looks like it doesn't use structs as enum fields, I might want to do the same.

[tomprince]

One thing that I noticed when implementing a very simple consumer of full_moon, is that there are a lot places where you need to destructure enums where by the design of the ast, there can only be one type of token, but that is not reflect in the types. I noticed this in particular for identifiers and string literals.

I've been pondering how to one could handle this:

1. store things like identifiers and literals directly
2. since we want to keep track of trivia, split trivia tokens into their own enum
3. s/TokenRefrence/WithTriva<T>/, and parameterize it over the type it holds.

---

syn looks like it doesn't use structs as enum fields, I might want to do the same.

I presume you mean not using enum struct variants? It appears that enum uses tuple variants with a single struct as the value everywhere. If we did that for tokens (say), then we could store those structs directly in the ast for the appropriate nodes (possibly wrapped by a WithTrivia, rather than the token enum itself; which would eliminate the need to destructure the token when we know the variant we should have.

[Kampfkarren]

I presume you mean not using enum struct variants?

Yeah. Basically, instead of this:

pub enum Index<'a> {
    Brackets {
        brackets: ContainedSpan<'a>,
        expression: Expression<'a>,
    },
    Dot {
        dot: Cow<'a, TokenReference<'a>>,
        name: Cow<'a, TokenReference<'a>>,
    },
}

...it would be:

pub enum Index<'a> {
    Brackets(IndexBrackets<'a>),
    Dot(IndexDot<'a>),
}

This turned out to look like it would be useful when I was implementing rlua bindings, since dealing with structs directly turned out to be way easier than the enum structs.