samhh
`when` and `unless` to extend from `Pointed` instead of `Applicative`?
These two:
- https://samhh.github.io/fp-ts-std/modules/Applicative.ts.html#when
- https://samhh.github.io/fp-ts-std/modules/Applicative.ts.html#unless
In case of fp-ts which has Pointed type class to support the of, seems unnecessary to require Applicative here, no?
Code should generally follow the principle of least power for typeclass constraints. In this case however I don't think Pointed is widely used in either Haskell or PureScript, and there's a minor discoverability benefit to limiting things to the "core" typeclasses.
I've never seen a use case for Pointed specifically that didn't also call for Applicative. Do you have a real world example?
Yeah, I know that Pointed typeclass sits in a odd position in today's FP constructions, however for what it's worth, in current scope of fp-ts it still plays the lifting part.
I've never seen a use case for
Pointedspecifically that didn't also call forApplicative. Do you have a real world example?
It occurred to me in the case of choose between when(Task.ApplicativePar) and when(Task.ApplicativeSeq), then just realized it makes no difference after reading the implementation underneath:
https://github.com/samhh/fp-ts-std/blob/b0072c9c3caeea427ea35f291d819ce41d5b502a/src/Applicative.ts#L70-L74
To be clear, this is only a suggestion that might fit with current fp-ts more economically, perhaps less correct in semantic terms.
You're right technically but for me it's a case of whether or not there's any real world use cases. I'm cognisant of how hard fp-ts' docs are to read largely on account of these countless intermediary typeclasses that in my experience aren't used much in practice, unlike for example applicatives.
I'm going to close this, but if some real world use cases for a Pointed but not Applicative abstraction pop up I'd be happy to revisit. In the meantime if anyone needs this you can safely redefine the relevant exports with an assertion as per the internals.