You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is not the hugest of problems, but I wanted to write this down because I looked at it again recently.
We have two obstacles to easily generating random ASTs to test:
defsDecl directly reference Def from an AST production, and it's hard to actually generateDef because they're supposed to be decorated references to elsewhere in the tree.
maybeDecl includes a function as a child, and it's not really feasible to generate random functions. So this too is troublesome.
One the one hand, maybe we can just not generate these productions, problem solved, but it would kinda be nice if the AST design were such that we could freely generate random trees. I think it might not be too hard to specially handle defsDecl but I think it might be nice to make maybeDcl more restricted. I believe it's always used to only introduce a declaration if it doesn't already exist, so perhaps there is an alternative design we could go with for that.
BTW, I got the random testing technically working again, and it immediately identified warnExpr in the host language as an interfering production, which already has a comment on it to that effect.
The text was updated successfully, but these errors were encountered:
defsDecl really only exists because Def is a closed nonterminal now, and so we need a non-interfering way of inserting these in defs. This should never be used with host Defs, in fact I think there's a comment somewhere to that extent but I'm too lazy to go check. I don't really know what the theory is for randomized testing of ASTs with closed nonterminals (or if that was ever fully thought through?) but this production is probably best to just ignore for now, or something.
It should be possible to do away with maybeDecl - I introduced this as a general-purpose helper but in practice the only places it is used are in implementing the other maybe*Decl helper productions. It should be easy to implement these directly instead.
This is not the hugest of problems, but I wanted to write this down because I looked at it again recently.
We have two obstacles to easily generating random ASTs to test:
defsDecl
directly referenceDef
from an AST production, and it's hard to actually generateDef
because they're supposed to be decorated references to elsewhere in the tree.maybeDecl
includes a function as a child, and it's not really feasible to generate random functions. So this too is troublesome.One the one hand, maybe we can just not generate these productions, problem solved, but it would kinda be nice if the AST design were such that we could freely generate random trees. I think it might not be too hard to specially handle
defsDecl
but I think it might be nice to makemaybeDcl
more restricted. I believe it's always used to only introduce a declaration if it doesn't already exist, so perhaps there is an alternative design we could go with for that.BTW, I got the random testing technically working again, and it immediately identified
warnExpr
in the host language as an interfering production, which already has a comment on it to that effect.The text was updated successfully, but these errors were encountered: