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

Rename WeaklyDecidable? #2404

Open
jamesmckinna opened this issue Jun 9, 2024 · 4 comments
Open

Rename WeaklyDecidable? #2404

jamesmckinna opened this issue Jun 9, 2024 · 4 comments

Comments

@jamesmckinna
Copy link
Contributor

In #2330 / #2336 @JacquesCarette objects to the term-of-art WeaklyDecidable (under Relation.Unary and Relation.Binary.Definitions) as the predicate/relation lifting of Maybe to proxy for (the result type of) semi-decidable properties (just =def "definitely true, with a witness"; nothing =def "don't know"), where by contrast with the usual recursion-theoretic terminology, because functions returning a 'WeaklyDecidable' result are by assumption total, we have a slightly sharper meaning/intention than being 'merely' semi-decidable...

So a question arises, as to whether we continue with the (arguably, unsatisfactory) present terminology/naming, or deprecate in favour of something else... in which case what?

I guess I personally could be happy with SemiDecidable, provided we comment appropriately as to the above sharpening of the usual meaning... alternatively such a name could be reserved for (a renaming of) the codata notion of Delay... in which case what do we call "total semi-decidable properties"? (I hope not TotalSemiDecidable! ;-))

@JacquesCarette
Copy link
Contributor

TotalSemiDecidable for the name of the abstract property seems fine. As a root for the naming convention for 'instances', I agree that it is awful.

decYes ? As in 'decide but give me evidence just in the Yes case'? All Agda functions are total, so we don't need to have that knowledge in the function name. decIsYes ?

weakDec is oddly biased and it's not clear in its name. Hmm, squashNo for the current weakDec? forgetNo?

@jamesmckinna
Copy link
Contributor Author

Reflecting on #2330 / #2336 and #2059 / #2405 , it's hard not to think that the use of Maybe should perhaps itself be deprecated, given that the From-*/from-* idiom provides a dependently-typed version of Maybe, with Data.Unit.Polymorphic.Base.⊤ proxying for nothing...

One thing that is noteworthy about the use of Maybe in the *.*Solver modules (and perhaps elsewhere) is that there is/seems to be no attempt made to leverage do-notation for the Maybe monad in order to streamline its use. Using Maybe might seem defensible on the model of 'emulate haskell where possible', but we seem not to be getting the best of either world-view...?

@JacquesCarette
Copy link
Contributor

I wouldn't quite use 'deprecate' to describe the situation, although I think we agree on the core: we have to opportunity to benefit from dependent types here, and yet by being too Haskell-like, we don't, even when we could (i..e do). Certainly most Maybe-based APIs should be critically revisited with an eye towards more evidency-yielding APIs.

Maybe is not very far away from "boolean blindness" after all.

@jamesmckinna
Copy link
Contributor Author

'Maybe myopia'?

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