Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Difficulty generating random ASTs #112

Open
tedinski opened this issue Aug 7, 2018 · 3 comments
Open

Difficulty generating random ASTs #112

tedinski opened this issue Aug 7, 2018 · 3 comments

Comments

@tedinski
Copy link
Member

tedinski commented Aug 7, 2018

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:

  1. defsDecl directly reference Def from an AST production, and it's hard to actually generate Def because they're supposed to be decorated references to elsewhere in the tree.
  2. 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.

@krame505
Copy link
Member

krame505 commented Aug 7, 2018

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.

@krame505
Copy link
Member

krame505 commented Aug 7, 2018

By the way, do you have a branch somewhere or something where you are developing this? I would be interested in taking a look.

@tedinski
Copy link
Member Author

tedinski commented Aug 7, 2018

The hacky code is already in the silver compiler (treegen extension) and the testing code I have is just a fixed version of what's in https://github.com/melt-umn/ableC/tree/develop/grammars/edu.umn.cs.melt.ableC/testing

I'll just directly commit my changes to this file soon enough. I'm not going to bother with a pull request, since nothing outside this file uses it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants