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

Add a Field1 instance for GHC.Tuple.Unit #878

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

treeowl
Copy link
Contributor

@treeowl treeowl commented Jul 22, 2019

No description provided.

@@ -110,6 +111,9 @@ class Field1 s t a b | s -> a, t -> b, s b -> t, t a -> s where
instance Field1 (Identity a) (Identity b) a b where
_1 f (Identity a) = Identity <$> f a

instance Field1 (Unit a) (Unit b) a b where
_1 f (Unit a) = Unit <$> f a
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or should this be lazy???? I think all the tuple instances should be strict, but I know others disagree...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd vote to keep it the way you've written it, as it's consistent with the other Field1 instances that are currently defined. If others feel strongly about changing this convention, then I think it would be best to leave that to a separate issue.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other Field1 insances are inconsistent. See Pair f g a and (a, b).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, I'm not sure what I was thinking when I wrote https://github.com/ekmett/lens/pull/878/files#r306307359, as the tuple instances are indeed implemented using irrefutable pattern matches. Hrm. I don't personally have a strong opinion on this, but for the sake of avoiding this PR from being bogged down by bikeshedding, it might be wise to stick to the current convention for now and raise a separate issue about how to reconcile the strictness of the instances for tuples and Product.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have _1' for when you want to reduce leaks

@@ -110,6 +111,9 @@ class Field1 s t a b | s -> a, t -> b, s b -> t, t a -> s where
instance Field1 (Identity a) (Identity b) a b where
_1 f (Identity a) = Identity <$> f a

instance Field1 (Unit a) (Unit b) a b where
_1 f (Unit a) = Unit <$> f a
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd vote to keep it the way you've written it, as it's consistent with the other Field1 instances that are currently defined. If others feel strongly about changing this convention, then I think it would be best to leave that to a separate issue.

@@ -63,6 +63,7 @@ import Data.Profunctor (dimap)
import Data.Proxy (Proxy (Proxy))
import GHC.Generics ((:*:) (..), Generic (..), K1 (..),
M1 (..), U1 (..))
import GHC.Tuple (Unit)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the CI failures, I think this should be (Unit(..)).

@glguy
Copy link
Collaborator

glguy commented Jul 26, 2019

Most Field1 instances (everything but Pair and (:*:)) are lazy. I suspect these two were added later and their being strict is a mistake. We have _1' for recovering the strict behavior.

@RyanGlScott
Copy link
Collaborator

Unit is now named Solo, so it would be worth using the modern nomenclature in this code.

@phadej
Copy link
Collaborator

phadej commented Nov 1, 2021

We could depend on OneTuple to add Solo instances. We can still have instances for Unit separately where it exists.

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

Successfully merging this pull request may close these issues.

4 participants