-
Notifications
You must be signed in to change notification settings - Fork 237
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
Add Number
literals for any SuccessorSet
#2406
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tiny tweak and a question.
A potential problem (but not, perhaps, in practice?): the
will be distinct: the second, in particular, will be (needlessly) more strict in its implementation of Is this a genuine problem? If so, what's the 'best' way to finesse this, except via separate, 'hand-cut' implementations of |
I do wonder if this is a genuine problem, at least in the context of Agda. [It might be!] It feels like a conundrum that is more philosophical: is stdlib trying to support prove-first-program-second Agda, or something else? There's a different library for program-first-prove-sometimes for Agda. Of course, the most interesting would be prove-AND-program, with a purposefully symmetric operator in there. Agda sure doesn't feel ready for that. |
Returning to this comment, I wondered a lot about the first part: The second part, I don't really understand at all: how would we get a symmetric operator out of |
You are quite right that, structurally, stdlib feels program-first. But it is proof-first in its actual details, for the most part, i.e. the definitions in
My bad, what I wrote was not clear: I mean that 'AND' to be at the meta-level, to be a symmetric operation on 'prove' and 'program' as concepts! |
Back to the philosophical question: of course it makes no difference for Accordingly, I suggest either merging this now, or else putting to draft while I add all the |
Merging this now probably makes sense, but I'd want a concurring opinion - perhaps @gallais who has already looked at it? |
Fixes #1363
NB:
Algebra.Literals
rather thanAlgebra.Structures.Literals
Algebra.Bundles.SuccessorSet
fromℕ
, rather than defining that as the unique morphism fromAlgebra.Construct.Initial.SuccessorSet
UPDATED: made the definition local, to future-proof the APISuccessorSet
and associated boilerplate #2277 adds no new{Is}SuccessorSet
structures/bundles to existingAlgebra.*
norData.*
in order to be able to createNumber
instances; cf. discussion on the issue as to where/how to create the 'right' ones so that they are consistently implemented across the whole*Ring*
hierarchy in such a way as to have the 'right' properties...Issue:
module
parameter be supplied as aninstance
? as aRawSuccessorSet
?Could be v2.1 or v2.2?