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

differing types for either/maybe #176

Open
Risto-Stevcev opened this issue Aug 13, 2016 · 7 comments
Open

differing types for either/maybe #176

Risto-Stevcev opened this issue Aug 13, 2016 · 7 comments

Comments

@Risto-Stevcev
Copy link
Contributor

Risto-Stevcev commented Aug 13, 2016

either is not itself a type, but instead Left and Right are types. Similarly, maybe isn't a type but Just and Nothing are. I think Either and Maybe should be types that can either be Left/Right or Maybe/Nothing (like the Fantasy Land versions). This would make it more consistent in terms of situations where you need to type check (such as specs), but also to be able to implement ILookup for core.match for these types

@niwinz
Copy link
Member

niwinz commented Aug 16, 2016

Hmm, cats already has the concept of type for the monad, but it is called with different name: context. Also, you already can integrate with clojure.spec just using the existing predicates like cats.monad.maybe/maybe? or cats.monad.either/ether?

Can you explain a little bit more your problem?

@ghost
Copy link

ghost commented Aug 16, 2016

If you are interested in using Either and Maybe types in pattern matching, this library may come in handy.

@Risto-Stevcev
Copy link
Contributor Author

@niwinz Sorry I didn't explain this well. Maybe and Either are tagged sum types, but they aren't represented like this. As a result, there's no real general way of pattern matching sum types. If instead a solution like daggy gets integrated into Cats, then Maybe and Either types can be implemented in this way and automatically get pattern matching, and you could define ADTs that properly match over sum and product types in general.

This would avoid overly specific solutions that people would have to write like the lib that @dialelo linked to (thanks for linking that btw), and would bring it a lot closer to something like scalaz in terms of ability

@niwinz
Copy link
Member

niwinz commented Aug 16, 2016

@Risto-Stevcev the current implementation has its reasons and the main one is that clojure does not supports a way to express a sum types in the same way as haskell or scala does. If you have a idea on how to do it in clojure without introduce additional complexity, we are open to see new options ;)

@ghost
Copy link

ghost commented Aug 16, 2016

As a suggestion, if you figure out a way to encode sum types in Clojure(Script) it could be a good library on its own that cats can depend on.

@Risto-Stevcev
Copy link
Contributor Author

Yeah I think I'll try to and experiment on writing a library for that. The daggy lib and Fantasy Land ways of doing it aren't bad, and I might be able to find a way to couple it nicely with core.match so it feels closer to real adts. I know there also used to be a defadt lib in clojure so I might look at that also

@ghost
Copy link

ghost commented Aug 16, 2016

Looking forward to your work, please keep us posted!

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