-
Notifications
You must be signed in to change notification settings - Fork 273
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
base: master
Are you sure you want to change the base?
Conversation
@@ -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 |
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
.
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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(..))
.
Most |
|
We could depend on |
No description provided.