Giters

agda / agda-stdlib

The Agda standard library

Home Page:https://wiki.portal.chalmers.se/agda/Libraries/StandardLibrary

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Display of (redundant/deprecated) pattern synonyms

jamesmckinna opened this issue · comments

commented

An annoyance that seems to be due to this: the emacs tooling seems to prefer less-than-or-equal to _,_ when I do C-c C-c to pattern match on a product when both are in scope, regardless on whether the thing I'm matching has anything to do with natural numbers

Originally posted by @Taneb in #1948 (comment)

commented

If the pattern synonym is not in scope unqualified then it should not be used to resugar.

commented

If the pattern synonym is not in scope unqualified then it should not be used to resugar.

So is this an agda bug? an emacs issue?
Can it be locally/temporarily hacked with a DISPLAY pragma?

As for the original PR #1948 which introduced the pattern synonym for backwards compatibility, can such things be marked as deprecated? (I wasn't sure at the time)
And, now that it has been merged in to master, I suppose a follow-up PR which removes all the other uses of the redundant synonym might be in order? But how to trigger a warning to other users? And how to fix @Taneb 's problem? It's typical to import Data.Nat.Base unqualified, which introduces the synonym...

commented

If the pattern synonym is not in scope unqualified then it should not be used to resugar.

The issue is, it's very easy and common to have both the actual constructor, _,_, and the pattern synonym in scope, if someone imports both Data.Nat.Base and Data.Product.Base without an import list (I do this a lot)

So is this an agda bug? an emacs issue?

It could be called an agda bug, but I wouldn't be surprised if it's deliberate behaviour reasonable in some contexts.

Can it be locally/temporarily hacked with a DISPLAY pragma?

I don't think so? If I'm reading the Agda docs right, pattern synonyms have an implicit DISPLAY pragma

commented

So is this an agda bug? an emacs issue?

A design bug in the standard library?

For now, pattern synonyms are untyped (cf. agda/agda#2069) and so their resugaring also is.

commented

A separate issue might be, also/independently, to reconsider the refactoring, not in favour of reverting the changes, but in enhancing the definitions in Algebra.Definitions.RawMagma to be fully-fledged top-level records, rather than proxying via Σ-types? Sigh...

commented

So is this an agda bug? an emacs issue?

A design bug in the standard library?

Well, I introduced it... so I'd welcome a steer towards how best to fix it without having to tackle the RawMagma definition first.

For now, pattern synonyms are untyped (cf. agda/agda#2069) and so their resugaring also is.

Yes. But see above.

commented

OK, so after experimenting a bit, there seems to be a spectrum of 'solutions' to the problem, according to how much effort they require on the user's part vs that of the developer(s):

  • add hiding (less-than-or-equal) to all client imports of Data.Nat.Base; this is probably the easiest for the time being, but is perhaps maximally irritating to users;
  • deprecate the pattern synonym, and remove all uses of it from the library; this isn't a solution per se, unless coupled with the first suggestion; but would at least speed up adoption of the new representation; NB developing new proofs for the modules in which it was previously used is proving (sic) more tiresome than I had hoped/expected... :-(
  • remove the pattern synonym entirely, which may break client code unexpectedly, so needs careful documentation as a breaking change (this may end up being the simplest moststraightforward thing to do, however, modulo the above);
  • redevelop the RawMagma machinery (I don't see myself being able to do this for v2.0, so barring someone else's heroic effort, one of the above approaches needs to be taken otherwise).

Any offers as to which you/we/users might prefer/be able to tolerate as an interim stopgap? Any other alternatives?

commented

Add an extra cornercase to Agda so that we don't resugar pattern synonyms marked as DEPRECATED?
But of course the ergonomics would still be bad for people not living on the Agda bleeding edge.

Edit:

Ah but IIRC we don't really handle deprecated pattern synonyms? (at least it's the case for syntax: agda/agda#6915)
And we don't actually have DEPRECATED, we only have WARNING_ON_USAGE. 😧

commented

redevelop the RawMagma machinery (I don't see myself being able to do this for v2.0, so barring someone else's heroic effort, one of the above approaches needs to be taken otherwise).

This seems like the right thing to do. Looking at it, it shouldn't be that hard as it's not yet widely used. I'll see what I can put together.

commented

@gallais yes I found it was indeed ok to 'deprecate' pattern synonyms via WARNING_ON_USAGE, but that it would have required an Agda hack for such definitions to avoid the display folding (and at that point, really started to tear my hair out at the 'cure' being worse than the disease...)

commented

@MatthewDaggitt thanks for picking this up!?
one reason I hadn't mustered the energy to do this was feeling too burnt out to deal with the choices needed after the discussion with @JacquesCarette on the associated issue trail #2115 ... back to #1919 ...

... but maybe your solution is (simply!) the right way to go!?

I guess I couldn't/can't see far enough ahead to see if your solution avoids creating any hostages to fortune downstream... but that may very well be (my aiming for) the perfect being the enemy of the good (enough)... ;-)

commented

And ... hard not to feel that all of this arises for the sake of the original decision to avoid the breaking change of removing less-than-or-equal completely... sigh?