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

Generalizing TextualMonoid #25

Open
tysonzero opened this issue May 13, 2019 · 2 comments
Open

Generalizing TextualMonoid #25

tysonzero opened this issue May 13, 2019 · 2 comments

Comments

@tysonzero
Copy link

TextualMonoid has plenty of functionality that would be useful for non-Char containers, so I was thinking about ways to generalize it.

It seems like the core concept is that for a subset of FactorialMonoid's, the primes can fit a more restricted type than the original type, and can always be injected back into the original type with singleton. It seems like a decent abstraction is then to encode this directly:

class FactorialMonoid m => ContainerMonoid m where
    type Element m :: Type
    uncons :: m -> Maybe (Element m, m)
    singleton :: Element m -> m

And then the laws are basically that it is completely compatible with FactorialMonoid when you use uncons and singleton to roundtrip back and forth between element and container types.

Also on a side note it seems like it would be useful to tie FactorialMonoid into the existing Reductive* hierarchy somehow, particularly since it directly exposes splitPrimePrefix which seems like it should be related to stripPrefix in the form:

stripPrimePrefix c == Just (a, b) ==> stripPrefix a c == Just b

I'm still not 100% sure how this would ideally mesh with the regular Foldable/Functor hierarchy and things like Mono*, but I think the above should still be a nice thing to have and an improvement on focusing specifically on Char.

@blamario
Copy link
Owner

One of my goals with the library was to stay away from any language extensions, but as time passes there seems to be less and less point to it. I'm just not sure there's enough demand for a generalization, otherwise I'm open to it.

@tysonzero
Copy link
Author

After more research it seems like this new class would overlap more or less exactly with IsSequence from mono-traversable, so perhaps trying to merge in the other classes underneath IsSequence would be more efficient, to avoid duplication.

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

No branches or pull requests

2 participants