Bringing Data.Text into `base`: What is the next step?

#35

1.4. Release notes for version 6.8.1 (section 1.4.4) - well spotted, @ChShersh!

…since 6.8.1, has there been any other transfers of code away from base into other boot-libraries? If not, then comparing it to the current version of base could help to determine how things have (apparently) “gone awry”.

This information may not be able to help in salvaging base, but it could help to avoid making (most of) the same mistakes, if it’s impossible to practically separate GHC and base and the two have to be rebuilt.

#36

“there’s only two ways I know of to make money: bundling and unbundling.”

2 Likes
#37
#38

How much pain would be removed if cabal offered to edit your .cabal file to add the missing package build-depends if it sees you trying to import a module from a package you aren’t depending on?

$ cabal build
[snip...]
app/Main.hs:3:1: error:
    Could not load module ‘Data.Text’
    It is a member of the hidden package ‘text-1.2.5.0’.
  |
3 | import Data.Text
  | ^^^^^^^^^^^^^^^^

Automated fixes are available. Would you like to:

1. Do nothing
2. Add `build-depends: text ^>=1.2.5.0` to the target `app`
-- One of these for each `common` stanza imported by the target being built
3. Add `build-depends: text ^>=1.2.5.0` to the common stanza `deps`

Enter choice [1]: 2
Successfully updated `foo.cabal`; attempting rebuild.

Perhaps only show these hints if cabal is being run interactively, so that other build tools don’t get tripped up by a subprocess waiting for input?

2 Likes
#39

I believe that much of the frustration in this thread would be solved by (either of):

  1. Adding better default packages to cabal init (with an optional standard package)
  2. Having HLS suggest adding new packages when importing from a hidden package

There is already progress for (2) in HLS, and I encourage people to send some emojis/love to the relevant PR: https://github.com/haskell/haskell-language-server/pull/2954

(1) seems like a good thing to do. Please add feedback/support on the new issue in Cabal.

Let’s push for either of these solutions. We can always find the right solution after we pick the low-hanging fruit.

Also: a much hotter point of cabal frustration is module discovery. I encourage everyone to read the thread here and add thought to the conversation so that progress happens!

2 Likes
#40

This is not generally a job for cabal (which afaik does not know about type checking errors that come from GHC). But it’s certainly reasonable for HLS to handle.

#41

I don’t understand what this means. Boot libraries are already coupled to GHC versions: version history · Wiki · Glasgow Haskell Compiler / GHC · GitLab

#42

That is a very complicated design space. Package imports can be guarded by deeply nested if conditions: compiler, architecture, OS, flags,. …

At worst, HLS might try to add an unbuildable dep, because it doesn’t understand the context well enough (relationship of CPP directives to cabal flags etc).

I also feel this is slightly offtopic, to be honest.

#43

I’m under the impression that the conversation is moving away from the initial point.

While not having text available by default in every cabal project is a valid papercut, the point of moving text to base seems to be to start resolving this ridiculous situation where Haskell is one of the only language where the core apis are using a placeholder textual type (String) and most of the ecosystem is using another one (Text).

So, to come back to the original question: What is the nest step? What are the concrete blockers?
I’m not certain of what the transition plan would exactly look like: a new version of text that doesn’t do anything on newer ghc versions? I there a way to do this while still being compatible with libraries that depend on older text versions? Is it painful to upgrade the entire ecosystem to a new text version (I assumed we’ve learned that recently)

8 Likes
#44

How does that differ from adding module imports (which HLS already supports)?

1 Like
#45

Module imports don’t work well either in light of CPP, correct. Supporting cabal files will be even less reliable though. I can already think of a number of my packages, where it will not work well: e.g. when you have dedicated modules per platform.

1 Like
#46

For those motivated to make this happen, you should definitely contribute to the efforts to split base as discussed in: Pre-Pre-HFTP: Decoupling base and GHC. I expect @Ericson2314 would love your help in getting the ball rolling!

Although my suggestions are partial fixes (e.g. don’t account for dev flags), they solve a vast majority of the problems people have. Given the work involved in the full fix (which will take 1-2 _years), finding interim solutions is much more productive imo. We also might find that the small and easy fixes are enough to reduce the problem enough to not warrant the larger breaking changes.

#47

Some observations:

  • prior to version 6.8.1, the contents of the array boot library was part of base;

  • Data.Array is a standard type in Haskell 2010 (see Ch. 14 of the Report).

Two questions:

  • Since array appeared in version 6.8.1, has there been any problems with accessing the Data.Array type from standard Haskell 2010 automatically, as a result of that split?

  • If not, can the technique used for array for that purpose now also be used to bring the text library into Haskell circa. 2022?

If that is still possible, and practical:

  • text and base can then remain separated - base doesn’t get any larger;

  • the technique could then be used to split other portions of base into new separate libraries - base could get smaller;

  • the new libraries would be readily available, just like base and array are now.

2 Likes
#48

Draft: move base to ghc base, #20647 (!7898) · Merge requests · Glasgow Haskell Compiler / GHC · GitLab this is a very simple PR which almost works. Some just needs to debug the remaining Safe Haskell and TH test failures; I would love it if that someone were not me. After that is done I think splitting base up can proceed incrementally with assorted volunteer effort. This is the one and only stumbling block!

6 Likes
Pre-Pre-HFTP: Decoupling base and GHC
#49

(rant: And to be frank, I think that I am quite fed up by this Haskell Exceptionalism that is so pervasive in our culture to the point of justifying the worst design decision from the last millennium as if their rectification was an intolerable attack on our very being. I’m not only speaking of what this discussion brings but it is a general sentiment that strikes me when I read similar community debates.)

<neutral tone, not attacking you or anything>

Is this really Haskell Exceptionalism, though? Because if it is, Haskell can’t ever get it right.

Either we please the “let’s correct our mistakes” group, or we please the “think about backwards compatibility” group. In the first case, Haskell is unreliable, because stuff breaks all the time (including things like tutorials etc. so the educators would also get mad); and in the second case, we’re exceptionalist because we don’t want to change things?

I dunno, I feel like everyone’s always mad at Haskell, no matter which direction is chosen. :thinking:

4 Likes
#50

It’s more about the ecosystem than the language; namely there’s only one of them, and it’s (mostly) centred on GHC, Cabal and Hackage. This single resource is then being used for multiple and frequently-diverging purposes, hence the frustration and “burn-out”.

As it is now, the Haskell ecosystem has a curious resemblance to an OS distribution (GNU+Linux, BSD, GNU+BSD kernel, etc) - apart from the obvious absence of boot sectors, device drivers and other OS staples, there’s only one version (which could be called torment).

If I’ve used an OS distro with such an arrangement, I have completely forgotten it. I can only recall using ones with at least two versions:

  • current (stable for regular use)

  • future (testing for new features, etc.)

and people can then choose what’s best for their needs.

Whether or not the Haskell ecosystem could ever have a similar arrangement is a question I leave for those much more knowledgable on these matters…

#51

Personally, I love Haskell as it is and hope it will continue to improve. And I’m ready to pay for it by fixing all the stuff that’s getting broken. Maybe I just love fixing stuff AND seeing things change for the better :smiley:

5 Likes
#52

This long conversation has petered out. But I think the question asked at the beginning is still pertinent (if maybe better rephrased to be neutral on a solution):

Making Data.Text more available: What is the next step?

One item of broad consensus in this thread is that making the Text type more available would be good. Some want to move text into base, while others would want to keep Data.Text outside of base but make it more easily available in other ways, perhaps by incorporating Data.Text into an alternative to base or by making cabal more interactive in suggesting new packages. There may be yet other solutions that did not come up here.

Regardless, I’d like to propose a next step: pass this to the Technical Working Group of the Haskell Foundation, if they’ll accept the challenge. Right now, the TWG is designed around evaluating and acting on proposals brought forth from the community. However, the group of people comprising the TWG (to be clear: I’m not one of this group) is very well positioned to come up with a solution to this problem. And so, if @david-christiansen agrees, I wonder whether they could take this on and develop a concrete proposal in-house. In recognition of the expertise and doubtless thoughtful care this group will give, I urge us in the community to accept the direction they propose. It will be imperfect, but hopefully move us forward.

3 Likes
#53

When it comes to the discussion about base, this is clearly a CLC proposal. The TWG can of course raise CLC proposals as well, but that doesn’t mean they will get accepted.

I also would rather like to see CLC spearhead this in general and not be too shy about retaking more responsibility beyond base.

#54

I’ll follow up with the group and see if there’s interest in taking it up. Given that there are multiple paths to a solution, only some of which involve CLC proposals, I think it’s a reasonable forum in which to try to work out some ideas to then submit to the proper channels.

5 Likes