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

Autosubst notations #65

Open
MevenBertrand opened this issue Jan 21, 2025 · 3 comments
Open

Autosubst notations #65

MevenBertrand opened this issue Jan 21, 2025 · 3 comments

Comments

@MevenBertrand
Copy link
Member

When moving to 8.20, @kyoDralliam had to comment out a notation in the file generated by AutoSubst: there is a new warning about notations with incompatible prefixes, which this notation hits HARD. Afaict, any notation involving [ is forced by this to be set at level 1, which is quite horrible.

For now, the comment is a "hotfix", but this means we again cannot generate the Ast.v file with a simple recipe :( We really should have a better solution. @yforster do you think this should be fixed upstream in AutoSubst?

MevenBertrand added a commit that referenced this issue Jan 21, 2025
@yforster
Copy link
Member

Probably it should be fixed either in Coq or in AutoSubst. Why is this incompatible prefix thing introduced?

What would be the fix in Autosubst? Have an option to not generate any notations? Or just use a different symbol for this notation from 8.20 on?

@MevenBertrand
Copy link
Member Author

Afaiu the issue is that if you have two notations at different levels starting with the same token, the parser will have to always go for one instead of the other, which will silently be killed. This used to always exist, but there was a new added warning to let users know about it. In our case, I guess we never realised because we never use the scope Autosubst is using.

On the Autosubst side, I think we could

  • remove this one particular notation, which is afaict rather unnecessary
  • have an option not to generate notations at all (which would be I think a good step in the direction of saner notations anyway)

@MevenBertrand
Copy link
Member Author

I just realised that uds-psl/autosubst2#8 also has beef with the exact same notation. I can't reproduce their hard error on my side, but maybe another sign we should act on this.

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

No branches or pull requests

2 participants