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

Applicative instances #25

Open
int-index opened this issue Jan 8, 2021 · 8 comments
Open

Applicative instances #25

int-index opened this issue Jan 8, 2021 · 8 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@int-index
Copy link

In Data.Strict.Maybe, I see the following argument for omitting the Applicative instance:

-- Note that in contrast to the standard lazy 'L.Maybe' type, the strict
-- 'Maybe' type is not an applicative functor, and therefore also not a monad.
-- The problem is the /homomorphism/ law, which states that
--
--      @'pure' f '<*>' 'pure' x = 'pure' (f x)  -- must hold for all f@
--
-- This law does not hold for the expected applicative functor instance of
-- 'Maybe', as this instance does not satisfy @pure f \<*\> pure _|_ = pure (f
-- _|_)@ for @f = const@.

However, I don’t think it holds water, because by the same token Haskell doesn’t even have the State monad, see http://www.cse.chalmers.se/~nicsma/no-state-monad.html

Instead, I think the right thing to do is to acknowledge that type class laws typically hold only if we ignore bottom, and implement the usual Applicative and Monad instances for the strict Maybe (and other types in the library).

@infinity0
Copy link
Member

Sounds good to me, does @phadej have an opinion? A PR would be very welcome.

@phadej
Copy link
Contributor

phadej commented Jan 11, 2021

I do see a benefit of having functions with S.Maybe a -> (a -> S.Maybe b) -> S.Maybe b signature. And there is an obvious way. However I'm unsure whether it's wise to use strict Maybe as control structure, yet it's probably handy to be able to try to swap lazy Maybe to strict Maybe, as an experiment.

A PR adding the same instances https://hackage.haskell.org/package/base-4.14.1.0/docs/Data-Maybe.html#t:Maybe has is fine. As long as there is disclaimer which would allow us to close issues re. bottoms with "you have been warned".

@phadej
Copy link
Contributor

phadej commented Jan 11, 2021

TL;DR I'm quite sure there would be issues like "I swapped lazy maybe to strict maybe, and my program started to crash instead of running faster".

@infinity0
Copy link
Member

That would only affect new users that attempt to take advantage of this feature, though - it doesn't cause any backwards-compat issues as the instance doesn't exist currently so nobody would be using it.

@phadej
Copy link
Contributor

phadej commented Jan 11, 2021

Yes, I it won't break any existing code. I didn't mean that.

@phadej phadej added enhancement New feature or request help wanted Extra attention is needed labels Feb 23, 2021
@phadej
Copy link
Contributor

phadej commented Feb 23, 2021

Let us wait for a patch. I'd expect an instances come with a documentation of their partial lawfulness.

@tomjaguarpaw
Copy link

I'm confused by this because there is a Functor instance, but I don't believe Data.Strict.Maybe is technically a Functor:

> let f = const ()
> let g = const undefined
> fmap (f . g) (Data.Strict.Just ())
Just ()
> (fmap f . fmap g) (Data.Strict.Just ())
*** Exception: Prelude.undefined

Or did I misinterpret something?

@phadej
Copy link
Contributor

phadej commented Nov 3, 2021

@tomjaguarpaw we agreed to add instances. We are waiting for a patch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

4 participants