Maybe we can bundle the "small" changes and deliver them upstream along with bigger changes in a single release where all breaking changes can be listed. That way we can keep accepting the small changes that make sense and that ultimately build up to a much better experience without having library maintainers have to make 10 releases for items they may view as trivial individually.
@nomeata
2 жыл бұрын
Yes, I (too implicitly, maybe) always assumed that that is what will happen. Of course we wouldn't do a release just for this small change!
@LukeEvans0
2 жыл бұрын
If this is partly about notification and consultation with package writers about proposed changes and their putative effects for maintainers/developers, perhaps hackage could grow an extra feature to relate comment channels to owners of packages based on the features of those packages (usage of a certain dependency or language feature). That way, people proposing a change can say "Hey! We're planning on doing X" and people with known association to the relevant feature/library would be invited to a message stream on which issues can be discussed. Could even include a "consultation period" time limit for conversation and a voting system for collecting opinion on specific questions during that period.
@tricky778
Жыл бұрын
10:55 you can't choose the latter "forcing" unless you're planning on moving into the organised crime industry. You may only choose between the former or obscurity. But that's okay because you can generate changes to excellent affected modules programmatically. But that's unnecessary because maintaining compatibility is equivalent. Start now by requiring a language version mark in every haskell source code file in things like cabal and when ghc is run with a suitable validation flag, everyone benefits.
@zoltantoth1566
2 жыл бұрын
You doing the updates to other libraries is a horrible idea. You are already occupied by work that is very important and only you can do. Rather decrease the amount of breaking changes or introduce some mechanism that helps in keeping up with breaking changes [deprecation labeling | more automation in library version management | ...].
@luctielen
2 жыл бұрын
We need a industrial grade refactoring tool for Haskell, that can be used to auto update on the entire haskell ecosystem, that would solve so many of these problems.. things like "Monad of no return" proposal would also finally be possible then!
@iverbrnstad791
2 жыл бұрын
Dear Richard, you mention wanting to hear from "Haskell learners", as someone who identifies with said category, and would very much like to give back to the community, would you be willing to touch a bit on how we could? Do we just reach out to the CLC, or is there a process? Are there any particular qualifications you look for?
@Skyb0rg
2 жыл бұрын
I’m not sure if I agree that there is “no good reason” for including (/=) in the Eq typeclass. Notably: IEEE754 floats! (nan == nan) == (nan /= nan) == False How will this affect use of Double which do not have proper Eq instances? Especially since Double is part of base.
@Skyb0rg
2 жыл бұрын
I would probably say that Double shouldn’t really have an Eq instance, which is a sentiment shared by Standard ML. Though I think that change would not be something really accepted by the community.
@Skyb0rg
2 жыл бұрын
@Richard Eisenberg Hmm, I was not aware that GHC never implemented the IEEE standard. It seemed like this was the reason for having (/=) in base to begin with
@malkdk
2 жыл бұрын
It’s also worth noting that any module that imports (=/) as part of Eq - e.g. import X (Eq((=/))) - will break with this change. Not sure how widespread that is, though.
@Kram1032
2 жыл бұрын
At least one of the comments I've read on this basically amounted to "sure, do this, but like not on its own. Take a long hard look at Haskell Classes and roll this one change into that", implying there is, indeed, broader issues with Classes as they stand. And I think that makes sense: It would have given more time and visibility, It might have felt like a bigger improvement where it "actually makes sense" to break anything for the sake of it And it's easier to swallow one bigger change every so often rather than a constant stream of tiny ones. Now this is all contingent on there indeed being value in considering streamlining of Classes in general. But even if it's not that, it could have been rolled in with a different thing, just to provide a sense of reasonable amounts of stability. Heck, maybe there could be a "small issues and papercuts roundup" from time to time, that can, on a somewhat regular schedule, tackle larger groups of mini-proposals like this one.
@tricky778
Жыл бұрын
When (/=) is expressible more clearly than (==) then people would have to implement inequalMyType and say that (==) = not . inequalMyType. But that's rubbish. The extra parsing and bookkeeping can't be any better than using the law to optimise away one typeclass entry can it?
@pdr.
2 жыл бұрын
Regarding making people who make breaking changes responsible for fixing the packages that are affected downstream, I was just thinking exactly this yesterday and in my opinion, this should be extended to any package, not just base.
@q_rsqrt5140
2 жыл бұрын
What about performance? For some types equality is harder to prove then inequality.
@fendorbaradiel8950
2 жыл бұрын
Then you can just use `not (...)` for (==). While a bit silly, works alright, no? Additionally, I can imagine that GHC optimises (not . not) away.
Пікірлер: 19