-
Notifications
You must be signed in to change notification settings - Fork 36
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
Re-export pack, unpack and Text from Data.Text #208
base: master
Are you sure you want to change the base?
Re-export pack, unpack and Text from Data.Text #208
Conversation
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
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
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 |
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". |
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! |
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