Document tree

[conartist6]

Now that I'm confident in my technique for grammar definition and the basic factoring of the engine I'm moving on to filling in more of the JS grammar. It hasn't taken much filling in to realize something: the way I express grammar for a language is now quite similar to the way the prettier core does! Similar enough to merge into one set of definitions, I'd say. Currently my engine is agnostic to the precise way that a program's concrete syntax is stored. It may be stored as a string. It may be stored as a tree of token sequences. Basically what this means is that there's no reason my existing abstraction shouldn't work just fine when concrete syntax is stored in a doc tree structure like the one that prettier uses internally.

All this is to say: I basically realize that what I have been doing is creating a new prettier core. This code won't be a companion to prettier that facilitates renaming, it will essentially be prettier: a new version of prettier which has a few more tricks up its sleeve.

I feel like this is a revelation, but also I've had this thought in the back of my mind all along. I guess what I'm realizing is that it isn't just a long term pipe dream, it's the actual way forward right now.

[conartist6]

Ok I'm... not so sure about this anymore. I need a central visitor mechanism to keep all my state synced up. Prettier frequently passes control from printing of a parent node directly to the printing of a child, which then allows the printing of a child to depend on what its parent is.

[conartist6]

I think in a lot of places it'd be easy to transition prettier grammar towards using something more like a visitor pattern, as the recursion pattern is usually printNodeType(path, options, print). I've also identified printMemberChain as a particularly demanding example of prettier's logic, so I should look more into that.

[conartist6]

Closing for now.