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.

Sign up for GitHub

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

Jump to bottom

Explain how to write Show instances #221

Closed
neongreen opened this issue Mar 24, 2020 · 8 comments · Fixed by #228
Closed

Explain how to write Show instances #221

neongreen opened this issue Mar 24, 2020 · 8 comments · Fixed by #228

Comments

@neongreen
Copy link
Contributor

A workaround I found: if you add import qualified Prelude to your module, suddenly you can write Show instances as usual.
@neongreen
Copy link
Contributor Author

Look ma, no show:

> import Prelude (Show)
> show

<interactive>:2:1: error: Variable not in scope: show

Doesn't work:

> data Foo = Foo

> instance Show Foo where show Foo = Foo

<interactive>:3:25: error:
    ‘show’ is not a (visible) method of class ‘Show’

And now it does!

> import qualified Prelude
> instance Show Foo where show Foo = "Foo"

And show is still not in scope:

> show

<interactive>:8:1: error:
    • Variable not in scope: show

@gromakovsky
Copy link
Member

Interesting, I thought it was somewhere in the docs, but apparently it never went beyond Slack discussions.

Since show doesn't come from Show anymore, you can't write Show instances easily.

Looks like a good place (in README) to write how one can do it not easily (but still it looks quite easy).

Btw, we've been doing import qualified Text.Show which looks a bit better because one can easier realize what this import is for.

Martoon-00 added a commit that referenced this issue Apr 30, 2020
@Martoon-00
[#221] Replace unsafe "1" functions in Container
a5a3222 
Problem: `Container` typeclass contains several unsafe functions which
assume that list if not empty - `foldr1`, `foldl1`, `minimum` and
`maximum`.
Since universum mostly aimed to be used in business logic, it would be
nice to avoid such unsafe methods and make user ensure explicitly that
list is not empty.

Solution: as we did with `head`, we turn those methods into safe
variants returning `Maybe`. In next commits I will also add versions
which work with `NonEmpty` and unsafe versions.

We could provide potentially more efficient implementation for our new
safe methods in `instance Container NonEmpty`, but I don't do this for
now as it requires some benchmarking.
Martoon-00 added a commit that referenced this issue Apr 30, 2020
@Martoon-00
[#221] Add NonEmpty versions of "1" functions
3960564 
Problem: sometimes we know in types that using `foldr1` or `maximum` is
safe, would be nice to have a function which does not return `Maybe`.

Solution: as we did for `head`, here I add versions of those and similar
functions which work with `NonEmpty`.
Martoon-00 added a commit that referenced this issue Apr 30, 2020
@Martoon-00
[#221] Add unsafe versions of "1" functions
d9f9607 
Problem: sometimes user is completely sure that his structure is not
empty, he may want to use the original `foldr1` and `maximum` from
`Data.List`.

Solution: make those and similar functions be provided in `Unsafe`
module.
Martoon-00 added a commit that referenced this issue Apr 30, 2020
@Martoon-00
[#221] Update readme and changelog
cca2e51
@Martoon-00 Martoon-00 mentioned this issue Apr 30, 2020
Merged
9 tasks
Martoon-00 added a commit that referenced this issue May 1, 2020
@Martoon-00
fixup! [#221] Add NonEmpty versions of "1" functions
ffead7d
Martoon-00 added a commit that referenced this issue May 1, 2020
@Martoon-00
fixup! [#221] Add NonEmpty versions of "1" functions
c773bfc
Martoon-00 added a commit that referenced this issue May 1, 2020
@Martoon-00
fixup! [#221] Add NonEmpty versions of "1" functions
bb1ca55
Martoon-00 added a commit that referenced this issue May 4, 2020
@Martoon-00
[#221] Add NonEmpty versions of "1" functions
33787bb 
Problem: sometimes we know in types that using `foldr1` or `maximum` is
safe, would be nice to have a function which does not return `Maybe`.

Solution: as we did for `head`, here I add versions of those and similar
functions which work with `NonEmpty`.
Martoon-00 added a commit that referenced this issue May 4, 2020
@Martoon-00
[#221] Add unsafe versions of "1" functions
3e3d12a 
Problem: sometimes user is completely sure that his structure is not
empty, he may want to use the original `foldr1` and `maximum` from
`Data.List`.

Solution: make those and similar functions be provided in `Unsafe`
module.
Martoon-00 added a commit that referenced this issue May 4, 2020
@Martoon-00
[#221] Update readme and changelog
7e497a4
Martoon-00 added a commit that referenced this issue Jun 2, 2020
@Martoon-00
fixup! [#221] Update readme and changelog
598e55f
Martoon-00 added a commit that referenced this issue Jun 2, 2020
@Martoon-00
[#221] Update readme and changelog
c37db78
Martoon-00 added a commit that referenced this issue Jun 2, 2020
@Martoon-00
[#221] Replace unsafe "1" functions in Container
6c9d641 
Problem: `Container` typeclass contains several unsafe functions which
assume that list if not empty - `foldr1`, `foldl1`, `minimum` and
`maximum`.
Since universum mostly aimed to be used in business logic, it would be
nice to avoid such unsafe methods and make user ensure explicitly that
list is not empty.

Solution: as we did with `head`, we turn those methods into safe
variants returning `Maybe`. In next commits I will also add versions
which work with `NonEmpty` and unsafe versions.

We could provide potentially more efficient implementation for our new
safe methods in `instance Container NonEmpty`, but I don't do this for
now as it requires some benchmarking.
Martoon-00 added a commit that referenced this issue Jun 2, 2020
@Martoon-00
[#221] Add NonEmpty versions of "1" functions
cb51b8e 
Problem: sometimes we know in types that using `foldr1` or `maximum` is
safe, would be nice to have a function which does not return `Maybe`.

Solution: as we did for `head`, here I add versions of those and similar
functions which work with `NonEmpty`.
Martoon-00 added a commit that referenced this issue Jun 2, 2020
@Martoon-00
[#221] Add unsafe versions of "1" functions
0f32c20 
Problem: sometimes user is completely sure that his structure is not
empty, he may want to use the original `foldr1` and `maximum` from
`Data.List`.

Solution: make those and similar functions be provided in `Unsafe`
module.
Martoon-00 added a commit that referenced this issue Jun 2, 2020
@Martoon-00
[#221] Update readme and changelog
eef65db
Martoon-00 added a commit that referenced this issue Jul 1, 2020
@Martoon-00
Merge pull request #223 from serokell/martoon/#221-safer-maximum
709a21e 
[#221] Safer maximum and stuff
@neongreen
Copy link
Contributor Author

May you and your kin prosper for a thousand years

@gromakovsky
Copy link
Member

@Martoon-00 did you close it by mistake?

@neongreen
Copy link
Contributor Author

Oh

@gromakovsky
Copy link
Member

Btw, we've been doing import qualified Text.Show which looks a bit better because one can easier realize what this import is for.

Another reason for it is that if you use base-noprelude or mixins to make Prelude refer to Universum (or your own custom prelude based on Universum), import qualified Prelude probably won't work. When we talk about custom preludes it sometimes might be the case that Prelude is not Prelude from base.

I guess I have spare 10 minutes to do this issue, a PR should come shortly.

gromakovsky added a commit that referenced this issue Jul 1, 2020
@gromakovsky
[#221] Explain how to write Show instances
08706d0 
Problem: if you manually define `Show` instance and switch to
`Universum`, they will fail to compile. It's a gotcha we don't mention.
Solution: mention it in gotchas and the migration guide.
@gromakovsky gromakovsky mentioned this issue Jul 1, 2020
Merged
9 tasks
gromakovsky added a commit that referenced this issue Jul 1, 2020
@gromakovsky
[#221] Explain how to write Show instances
26e9d74 
Problem: if you manually define `Show` instance and switch to
`Universum`, they will fail to compile. It's a gotcha we don't mention.
Solution: mention it in gotchas and the migration guide.
@gromakovsky
Copy link
Member

:nate: #228

@gromakovsky gromakovsky reopened this Jul 1, 2020
@Martoon-00
Copy link
Member

@Martoon-00 did you close it by mistake?

Yep, sorry :/

gromakovsky added a commit that referenced this issue Jul 1, 2020
@gromakovsky
Merge pull request #228 from serokell/gromak/#221-explain-show
04932ab 
[#221] Explain how to write Show instances
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[#221] Explain how to write Show instances serokell/universum
3 participants
@neongreen @gromakovsky @Martoon-00