// FIXME: Consider deepcopying the tree once, and then mutating that tree, instead of doing everything immutably; this might be significantly faster when a few iterations are needed to stabilize the tree, as that might otherwise result in many copies of the subtree(s) leeding up to the changed node(s), one for each iteration.
// FIXME: Consider whether inverting the evaluation order (deepest-first rather than shallowest-first) can remove the need for multiple optimization passes and stabilization detection.
// FIXME: Verify that changed nodes actually result in a change in where the walker goes!
// FIXME: Dirty tracking for stabilization detection
functionapplyVisitors(node,visitors){
if(visitors==null){
// We handle this here to make the `handle` pipeline more readable
returnnode;
}else{
letlastNode=node;
for(letvisitorofvisitors){
// eslint-disable-next-line no-loop-func
let{value:result,time}=measureTime(()=>{
returnvisitor.func(lastNode);
});
timings[visitor.name]+=time;
if(result===NoChange){
// no-op
}elseif(result==null){
thrownewError(`A visitor is not allowed to return null or undefined; if you intended to leave the node untouched, return a NoChange marker instead`);
}elseif(result===RemoveNode){
debuggers[visitor.name](`Node of type '${typeOf(lastNode)}' removed`);
lastNode=RemoveNode;
break;// Node has gone stale, stop applying visitors to it
}elseif(result.__raqbASTNode===true){
// New subtree to replace the old one
if(result===node){
// Visitor returned the original node again; but in this case, it should return NoChange instead. We enforce this because after future changes to the optimizer implementation (eg. using an internally-mutable deep copy of the tree), we may no longer be able to *reliably* detect when the original node is returned; so it's best to already get people into the habit of returning a NoChange marker in those cases, by disallowing this.
thrownewError(`Visitor returned original node, but this may not work reliably; if you intended to leave the node untouched, return a NoChange marker instead`);
}else{
debuggers[visitor.name](`Node of type '${typeOf(lastNode)}' replaced by node of type '${typeOf(result)}'`);
lastNode=result;
break;// Node has gone stale, stop applying visitors to it
}
}else{
thrownewError(`Visitor returned an unexpected type of return value: ${util.inspect(result)}`);
}
}
if(lastNode!==node){
// We re-evalue the new node before leaving control to the children handler, as the old one has been substituted, and therefore new visitors might be applicable.
returnhandleSelf(lastNode);
}else{
returnlastNode;
}
}
}
functionhandleSelf(node){
returnsyncpipe(node,[
(_)=>applyVisitors(_,visitors[_.type]),
(_)=>applyVisitors(_,visitors["*"]),
]);
}
functionhandleChildren(node){
// FIXME: Eventually hardcode the available properties for different node types (and them being single/multiple), for improved performance?
// NOTE: We assume that if an array in an AST node property contains one AST node, *all* of its items are AST nodes. This should be ensured by the input wrapping in the operations API.
changedProperties[property]=value
.map((item)=>handle(item))
.filter((item)=>item!==RemoveNode);
}else{
// Probably some kind of literal value; we don't touch these.
// FIXME: Think carefully about whether there is *ever* a valid reason to remove a single node! As array items are already taken care of above, and leave an empty array at worst, which can make sense. Possibly we even need to encode this data into node type metadata.
for(let[key,value]ofObject.entries(newNode)){
if(value===RemoveNode){
deletenewNode[key];
}
}
returnnewNode;
}
}
functionhandle(node){
// FIXME: Possibly optimize the "node gets returned unchanged" case, somehow? Perhaps by propagating the NoChange marker? But object creation is fast, so that may actually make things slower than just blindly creating new objects...