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

List.length is a monoid homomorphism #1857

Closed
Taneb opened this issue Oct 24, 2022 · 4 comments · Fixed by #1863
Closed

List.length is a monoid homomorphism #1857

Taneb opened this issue Oct 24, 2022 · 4 comments · Fixed by #1863

Comments

@Taneb
Copy link
Member

Taneb commented Oct 24, 2022

We should probably also add raw magma and monoid bundles to Data.List.Base as an extension to #1755.

@jamesmckinna
Copy link
Contributor

jamesmckinna commented Oct 24, 2022

EDITED As with my comment to issue #1851, it's not obvious to me where homomorphisms (and proofs that they are such) properly belong. We might (and will?) carry on making honourable exceptions for ones such as List.length here, but at some point either the imports will get so heavy (or even circular, if we seek to show two structures isomorphic), or else Data.X.Base Data.X.Properties ends up that way.

@Taneb
Copy link
Member Author

Taneb commented Oct 24, 2022

In this case I was expecting to put it in Data.List.Properties in the "Properties of _++_" section. We'll need length-++ to prove these in any case, so it can't go in Data.List.Base.

@MatthewDaggitt
Copy link
Contributor

@jamesmckinna, apart from the lack of symmetry, what is wrong with putting them in Properties files?

@jamesmckinna
Copy link
Contributor

jamesmckinna commented Oct 24, 2022

@Taneb I agree they they perhaps 'properly' belong in Data.List.Properties, but for the frequent refrain that these fundamental modules in the hierarchy groan under their own weight. I hadn't intended that they go in .Base, sorry for the implied confusion --- hope that the revised edit above makes this clear(er).

But, to answer @MatthewDaggitt 's question, it was my own thinking about Parity and Sign that had got me wondering about where things should go (plus a nod to @JacquesCarette 's frequent calls for 'thinner' modules), and the sense that while the lemmas that are required to show that length is a homomorphism might belong in Properties, the structure which bundles that data (function plus proofs) does/might not. Not least because the homomorphism property (and even its existence by virtue of freeness of List) is a higher-level API for length than the mere assemblage of properties as above. But indeed, in the symmetric cases such as isomorphism, there is a genuine question if we are not to have circular imports.

So not so much a question of 'wrong' as one of 'where best?'. But happy to take the push-back. EDITED and as per @MatthewDaggitt 's comment on #1852, I'll move discussion to a fresh general issue.

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

Successfully merging a pull request may close this issue.

3 participants