-
Notifications
You must be signed in to change notification settings - Fork 39
Re-export pack, unpack and Text from Data.Text #208
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
base: master
Are you sure you want to change the base?
Re-export pack, unpack and Text from Data.Text #208
Conversation
sjakobi
left a comment
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.
Thanks for the PR, @newhoggy!
I'm pretty apprehensive about enhancing the code and API for the -f-text variant, but maybe I just need to better understand the motivation.
e834f12 to
4ad9ad5
Compare
|
I've adopted the recommendations in #207 (comment) |
4ad9ad5 to
cfa3bdb
Compare
sjakobi
left a comment
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.
Unfortunately I have some concerns about the "future-proofness" of this approach.
|
Please ignore the CI failure BTW. It's probably related to https://gitlab.haskell.org/haskell/ghcup-hs/-/issues/123. |
cfa3bdb to
b47307b
Compare
sjakobi
left a comment
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.
Thanks!
Can you take a look at the failing CI jobs? Ignore the no-text job with GHC 7.10.3, which is broken, but should hopefully be fixed soon (#212).
|
CI on master should be fixed now. Please rebase! |
2e420c2 to
26d8dd4
Compare
d80f3d5 to
e84d9fa
Compare
|
The workflow for this PR is not running, but I've verified it builds independently here: input-output-hk#1 |
sjakobi
left a comment
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.
Looking good.
One (hopefully) last issue for me:
Since the new modules will be included in the PVP scheme, I think it would be best if we had explicit export lists there. Otherwise, it would be easy to change or remove one of the exposed functions without doing the necessary major version bump.
| -- Legitimate examples of packages that must have text as an optional dependency, include text (or | ||
| -- bytetring). |
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.
| -- Legitimate examples of packages that must have text as an optional dependency, include text (or | |
| -- bytetring). | |
| -- Legitimate examples of packages that must have text as an optional dependency, include text and | |
| -- bytestring. |
Same suggestion for the other new modules.
4d3b61f to
04b5f99
Compare
|
Added explicit export list and updated the docs "or" -> "and". |
sjakobi
left a comment
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.
One wibble left.
Thank you! This was more work than expected.
…ies being able to write code compatible with the fake text module
04b5f99 to
10c94e5
Compare
|
I've pushed the requested updates. |
|
Will we be able to merge this? |
|
Ping, @quchen! |
quchen
left a comment
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.
LGTM. The whole »emulating text« part is new to me so I did some digging; it makes quite a bit of sense now that Prettyprintert is becoming more and more standard.
prettyprinter/bench/LargeOutput.hs
Outdated
| {-# LANGUAGE DeriveGeneric #-} | ||
| {-# LANGUAGE FlexibleInstances #-} | ||
| {-# LANGUAGE OverloadedStrings #-} | ||
| {-# LANGUAGE TypeSynonymInstances #-} |
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.
Is this change still necessary? I don’t see a change that would require those exts in this file.
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've removed FlexibleInstances and TypeSynonymInstances. Hopefully it still works. Please approve workflows.
| , Prettyprinter.Util.Compat.Text | ||
| , Prettyprinter.Util.Compat.Text.IO | ||
| , Prettyprinter.Util.Compat.Text.Lazy | ||
| , Prettyprinter.Util.Compat.Text.Lazy.Builder |
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.
These will show up on Hackage, cluttering the package overview quite a bit – half of the whole package is already compatibility stuff. I don’t think there’s a way around this, or is there?
Optparse-Applicative is a very popular lib, so allowing Prettyprinter there would be a good thing. But I’m not a fan of cluttering prettyprinter’s public API just so some other package can retain eternal backwards compatibility – why can’t they depend on Text after all? Feels like a pretty strange design decision in anything later than 2010.
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.
Perhaps one option is to move these to a separate package altogether?
Re-export some Data.Text modules for the purpose of downstream libraries being able to write code compatible with the fake text module
Related issue: #207