Skip to content

Conversation

@infinity0
Copy link
Member

@infinity0 infinity0 commented Apr 20, 2021

I'm experimenting with de-duplicating StrictPair/StrictMaybe out of the containers library and need this flag to break the dependency cycle strict -> binary -> containers -> strict.

@infinity0 infinity0 changed the title Add a flag for avoiding the binary dependency Add a flag for avoiding various boot libs Apr 20, 2021
@phadej
Copy link
Contributor

phadej commented Apr 21, 2021

Is this discussed with maintainers of containers (and GHC). Until then I'll leave this unmerged.

@infinity0
Copy link
Member Author

Well, sjakobi had expressed a potential interest in having strict-containers be part of containers, and one stepping stone to that would be to have strict also as a dependency. A concrete discussion hasn't started yet, but it's easier to have one when I can open a PR that tests OK on CI. To do that it would be necessary to release these PRs, then one can add the necessary constraints: flags to cabal.project as part of a demo PR to containers.

@phadej
Copy link
Contributor

phadej commented Apr 21, 2021

I really want to be sure about that GHC is fine of containers adding strict as dependency and making strict (and these) boot libraries and potentially causing some dependency reversals. I want to see a discussion about this. Therefore I tag @chessai @emilypi, @bgramari @treeowl

I'm in support of pushing that all that code into "bundled with GHC" basket, but there have to be a broad agreement and clear plan.

Concretely: boot flag is no-go if strict becomes an actual boot library, the "commented-out" code have to go somewhere.

@infinity0
Copy link
Member Author

Yes, there is further work to be done if it were actually a boot library. My point was that having this PR included in a release on Hackage, makes it easier to explore the possibilities because then public PRs don't need to point to private copies of strict or these.

The discussion is a little bit premature at the moment because I didn't explore the issue concretely yet, but I imagine turning Map, HashMap, etc into typeclasses containing basic constructors/destructors as methods, so that separate lazy vs strict types can implement those, similar to how Vector.Generic works already. Not sure if @sjakobi had any other thoughts. But I meant to take this slowly, didn't want to rush anyone into a discussion yet.

@phadej
Copy link
Contributor

phadej commented Apr 21, 2021

I'm not accepting experimental features in proper releases, master.

Make a sdist from a branch, upload it somewhere, use packages: https://.../these-999.9.tar.gz in cabal.project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants