Re-export pack, unpack and Text from Data.Text#208
Re-export pack, unpack and Text from Data.Text#208newhoggy wants to merge 2 commits intohaskell-prettyprinter:masterfrom
Conversation
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.
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
|
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.
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.
| -- 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.
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.
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.
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.
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.
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.
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