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
--lossy-unification
in Agda 2.6.3
#6337
Comments
Yeah, makes sense to not bluntly remove syntax from one release to another, and this also applies to command-line and pragma syntax. (With some hesitation whether this principle should also apply to experimental, undocumented features like Shouldn't be hard to add a mechanism for the substitution |
Chefsache. |
`checkOpts` is just excluding `--vim` and `--only-scope-checking`, it does not modify the options record any longer (maybe did so in the past). Thus, it's type can be simply `m ()` (for a `MonadError m`). `unsafePragmaOptions` took `CommandLineOptions` as arguments but ignored it, so I zapped it. This allowed to simplify code elsewhere.
`checkOpts` is just excluding `--vim` and `--only-scope-checking`, it does not modify the options record any longer (maybe did so in the past). Thus, it's type can be simply `m ()` (for a `MonadError m`). `unsafePragmaOptions` took `CommandLineOptions` as arguments but ignored it, so I zapped it. This allowed to simplify code elsewhere.
`checkOpts` is just excluding `--vim` and `--only-scope-checking`, it does not modify the options record any longer (maybe did so in the past). Thus, it's type can be simply `m ()` (for a `MonadError m`). `unsafePragmaOptions` took `CommandLineOptions` as arguments but ignored it, so I zapped it. This allowed to simplify code elsewhere.
It is more user-friendly to not flatly rename a commandline or pragma option, but to keep the old name around with a deprecation warning. This commit sets up the necessary infrasturcture and applies it to the renaming from --experimental-lossy-unification to --lossy-unification. Also adds the first testcase for the --lossy-unification feature.
Price tag on this issue: 5000 SEK |
`checkOpts` is just excluding `--vim` and `--only-scope-checking`, it does not modify the options record any longer (maybe did so in the past). Thus, it's type can be simply `m ()` (for a `MonadError m`). `unsafePragmaOptions` took `CommandLineOptions` as arguments but ignored it, so I zapped it. This allowed to simplify code elsewhere.
It is more user-friendly to not flatly rename a commandline or pragma option, but to keep the old name around with a deprecation warning. This commit sets up the necessary infrasturcture and applies it to the renaming from --experimental-lossy-unification to --lossy-unification. Also adds the first testcase for the --lossy-unification feature.
`checkOpts` is just excluding `--vim` and `--only-scope-checking`, it does not modify the options record any longer (maybe did so in the past). Thus, it's type can be simply `m ()` (for a `MonadError m`). `unsafePragmaOptions` took `CommandLineOptions` as arguments but ignored it, so I zapped it. This allowed to simplify code elsewhere.
It is more user-friendly to not flatly rename a commandline or pragma option, but to keep the old name around with a deprecation warning. This commit sets up the necessary infrasturcture and applies it to the renaming from --experimental-lossy-unification to --lossy-unification. Also adds the first testcase for the --lossy-unification feature.
Thanks a lot for doing this. I am applying for a grant to pay for this. But I can also pay you with my hours in the future. |
@andreasabel, I suggest to create an issue with |
--lossy-unification
in Agda 2.6.3
Agda developers, thanks for accommodating the renaming of
--experimental-lossy-unification
to--lossy-unification
, which I asked for in a separate issue.Which I now realize will cause a problem for a few of us, not only in my project
TypeTopology
, but (at least) the cubical library.I wonder if we could still keep
--experimental-lossy-unification
as "deprecated" but still functional for a while, until everybody transitions from 2.6.2.2 to 2.6.3, which, of course, is going to take a while. We don't want to give trouble to our library users. Thank you.The text was updated successfully, but these errors were encountered: