Open conartist6 opened 1 year ago
Should CSTs include type: 'Gap'
nodes? I think so. I think it will be necessary in order to implement path.replaceWith()
.
In particular path
for a gap needs to know what the target of replacement in the tree is. Paths store this information as path.refToken.value
, which means that the parent should have that refToken
in its cstTokens
already. But we also need a place to store the gap token, particularly since trivial printing requires the \x00
value to exist in the tokens tree somewhere. It seems obvious to me to create a temporary child with cstTokens: [gapToken]
. That would also eliminate problems caused by the alternative: path.node === null
Gaps are going to need to be implemented at the same time as #27 because parsers are going to be the only reasonable way of creating trees with gaps in them, and no existing parsers will be able to do this for us.
It's nearly time!
Adding queries to this issue as they'll be necessary for working with gapped trees
This powerful feature allows some nodes of a complete tree to be missing. It will be possible to drag and drop fragments of existing code into a gap, and it should not be possible to accidentally create invalid programs this way.
It is expected that gaps in programs will be represented in serialized text as
\x00
(the null byte). This way it will be possible to store code with gaps as plain text (i.e. not a CST json structure). We will be able to rehydrate those null bytes with information from the grammar, parsing them into a gap token so that it is clear what they reference.