jaror: > We could simply write a script which automatically submits Hackage revisions to all your packages (I’m volunteering to write it). Revisions can’t change a dependency, this problem is not solvable with revisions.

I don’t understand why it is problematic to use a different name. If people actively depend on it, why wouldn’t they be able to change one name in their cabal files? I was thinking that there could be a kind of petition system to testify that a package is a vital resource of the community, but I don’t see how signing it would be less work than just changing the dependency. We could simply write a script which automatically submits Hackage revisions to all your packages (I’m volunteering to write it).

Each functioning state has ways to overrule the rights of an individual when the welfare of the society is at stake. E.g. if I owned a large forest in the middle of Germany and the state wanted to build new powerlines from North to South and needed them go through my forest, I could resist to sell, but eventually courts would rule that I have to give up parts of my property that the state needs. I find it ridiculous that we allow an individual to “own” a name on Hackage for the sole purpose of depriving the community of its use or to pickle a deceased package so that their great works can be admired undefiled for all eternity by posteriority. A package that has 100s or 1000s of dependents isn’t someones toy project anymore, but a vital resource of the community, and if the author has abandoned it I see no reason why the community should not be allowed to maintain it for the common good. We are missing a court that decides on such cases, though, and I don’t think there could be a simple rule. Difficult takeovers need to be decided on a case to case basis, balancing the rights of the individual with the needs of the community. And the judges need to be appointed in a transparent way.

taylorfausak: > This is hardly the first time this situation has happened. Consider the xml library. It hasn’t been updated in over 10 years. Does someone deserve to take it over? I don’t think so. ehh..well what if 1000s of packages relied on it transitively. And something happened (GHC evolution) that broke `xml` and now it needs some elbow grease. Now vanilla `cabal` just doesn’t work (and will _never work ever again_) for a huge part of the ecosystem. Everyone indirectly touching `xml` must now muck around with `cabal.project` or a Nix overlay or whatever `stack` uses for this sort of thing. So then let’s say the maintainer is contacted and they say “nah I’m not gonna update it. nah I’m not gonna accept any PRs and push updates to Hackage. nah I’m not gonna hand over ownership or even allow someone else to have the commit/update bit in addition to me.” then YES - that’s takeover time. `xml` is a good example here because it, like `basement` and `memory`, is a core building block other projects may stand on. taylorfausak: > To me the only reasonable solution is to allow namespacing packages by the maintainer’s name. Then we could have `@vincent/memory` and `@apotheca/memory` without issue. Namespacing is cool, but I don’t see how it would be functionally much different here than the whole “fork and rename” approach. The same toil would result - unless I’m missing smth.

i read through all the commentary, and this honestly smells to me as somewhat intellectually dishonest. “oh my package needs updating but you need my permission to use the unique identifier i own? your package manager should just be better and not let someone cause that problem.” “i don’t want to be responsible for supply chain attacks if i give someone else the commit bit. also, there shouldn’t be trustees at all who would take this responsibility.” the whole thing is more FUD and aesthetic theorycraft than practical concerns. definitely agree this is a package takeover loophole. Package versioning exists and is the solution to his problem. Future version could easily have different maintainers etc - his older versions are still sitting there unscathed by this would-be development.

olf: > Who would stop me if I, for each non-taken package name in the English dictionary and hyphenated combinations thereof, published a fork of acme-missiles under that name on Hackage and declare the same intent as Vincent? You would be banned by Hackage admins for clear vandalism. There’s a gray zone, but it’s miles away from that.

Another point in favour of namespacing: If the package is not in a stackage snapshot, stack allows to explicitly define a repo URL in stack.yaml which is effectively a namespace, isn’t it? How do other language communities handle package name uniqueness? A quick and shallow search indicates that e.g. both PyPi and NPM have adopted namespacing, while Rust’s crates.io also suffers from the uniqueness issue but allows for renaming your dependencies. Who would stop me if I, for each non-taken package name in the English dictionary and hyphenated combinations thereof, published a fork of acme-missiles under that name on Hackage and declare the same intent as Vincent?

Counterpoint - lack of updates does not indicate abandonment, it may indicate stability. `memory` and `basement` are both in need of maintenance to remain buildable, and both have been actively declared as abandoned _by their author_ so I hardly consider them to be in the same situation. On the other hand **I do find the notion of per-author namepacing to be worth considering as an alternative** to my own proposition, which is more of a “well what if” to serve as an alternative to doing nothing, than it is a seriously thought-out opinion. I’m mostly being mindful of the ever-growing load on indexing hackage, and on discoverability, and on how I don’t want to be doing _nothing_ about the problem.

taylorfausak: > You’re suggesting that we ignore his wishes because it’s inconvenient for us? That is exactly what he’s suggesting and I agree with him. You don’t try to replace things from the ground up (with basement, foundation, memory etc.), get people to depend on your packages, then have a burnout / change of heart and leave, while explicitly forbidding people from taking over maintenance to smooth out transitioning out of the resulting mess. He chose “violence” first, sorry not sorry. Not to mention that this is an interesting loophole that completely invalidates the “package takeover” process. Looks like it’s enough for an individual to publicly mention that he wishes nobody takes over their packages, then disappear forever and now package takeover process no longer can be applied?

This is hardly the first time this situation has happened. Consider the xml library. It hasn’t been updated in over 10 years. Does someone deserve to take it over? I don’t think so. To me the only reasonable solution is to allow namespacing packages by the maintainer’s name. Then we could have `@vincent/memory` and `@apotheca/memory` without issue.

Seeing as I am working on a total replacement for `memory`, which is effectively in the same position as `basement`, I feel as though I have an obligation to make my feelings known. I most certainly would like to name my own library `memory`, seeing as it _isn’t_ a fork of Vincent’s library, and the only thing stopping me is an abandoned corpse, yet I have accepted that I must settle for the alternative of `mem` or `memalloc`. However, the situation does create significant ire. It isn’t so much about the package itself, as it is the effective name-squatting that occurs as a result. Vincent has the rights to name his `memory` library, but I don’t necessarily agree that he should get the rights to that name on hackage in perpetuity. Why should we abide by the wishes of someone who has left the community? Vincent isn’t missing, but he also isn’t coming back, and his packages will continue to rot and pollute the namespace. He made his feelings known, a long time ago. A compromise might be found in tracking when a package has been effectively terminated eg after some time, and allow _the package name_ to be claimed by a new owner with the requirement of a completely new major version to signify the break in continuity, effectively being a new package under the same name as the old - even if it is eg a fork of that exact library under new ownership. Presumably this would never happen automatically, and would require some sort of name takeover request. The alternative is to imagine yet 10 years from now still, a library that hasn’t built in a decade, still taking up a prime name slot, because of a ghost. Haskell is already burdened with legacy issues, must we continue to add to them?

This feels like a bad precedent to set. Vincent isn’t missing; he explicitly left and said that he didn’t want others taking over his packages. You’re suggesting that we ignore his wishes because it’s inconvenient for us?

Call for proposals for the Haskell Implementors’ Workshop June 5, 2026 Organized by the Haskell Community Co-located with ZuriHac 2026 and Haskell Ecosystem Workshop 2026 Hosted by the Haskell Foundation at Eastern Switzerland University of Applied Sciences (OST) ## Overview * Deadline: April 10, 2026 * Notification: May 8, 2026 * Workshop: June 5, 2026 The 18th Haskell Implementors’ Workshop is to be held on June 5th 2026 alongside ZuriHac and the Haskell Ecosystom Workshop near Zurich. The event is organized by the Haskell Community and hosted by the Haskell Foundation at the University of Applied Sciences of Eastern Switzerland (OST) lakeside campus in Rapperswil, Switzerland. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure to share their work and to discuss future directions and collaborations with others. In the past the Haskell Implementors’ Workshop was co-located with ICFP (International Conference on Functional Programming). However, in recent years it has become more and more challenging to attract a large enough audience and sufficiently many speakers for an appealing program. ZuriHac and the Haskell Ecosystem Workshop have become an important annual gathering of a large part of the Haskell community. Following last year’s success, the Haskell Implementors’ Workshop will again be co-located with these events to be accessible to a broader audience. ## Scope and Target Audience The Haskell Implementors’ Workshop is an ideal place to describe a Haskell extension, describe works-in-progress, demo a new Haskell-related tool, or even propose future lines of Haskell development. Members of the wider Haskell community are encouraged to attend the workshop - we need your feedback to keep the Haskell ecosystem thriving. Students working with Haskell are especially encouraged to share their work. The scope covers any of the following topics. There may be some topics that people feel we’ve missed, so by all means submit a proposal even if it doesn’t fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimization and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment ## Talks We invite proposals from potential speakers for talks and demonstrations. We are aiming for 20-minute talks with 5 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. We will also have a lightning talks session. Lightning talks should be ~7mins and are scheduled on the day of the workshop. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Submissions can be made via the following form until **April 10, 2026** (anywhere on earth): https://forms.gle/S8fpAgFaFEvqoMqH6 Authors will be notified about the inclusion of their proposal in the final program by **May 8, 2026**. ## Program Committee * Andrew Lelechenko * Avi Press * Christiaan Baaij (chair) * Gergo Erdi * Jeffrey Young ## Contact * Christiaan Baaij

This may be a bit of an abrasive opinion, but I think that in this case, it would be reasonable to go against Vincent’s wishes, take over the `basement` name on Hackage, and publish a fork under it. It would be a bit of a hostile act, but as it stands, Vincent is effectively holding the package hostage - he won’t accept any contributions, he won’t fix it himself, but he also won’t allow anyone else to publish fixed versions in a way that they can be used as drop-in replacements (because that would require reusing the `basement` name on Hackage). This is exactly the kind of situation open source workflows are supposed to avoid; open source licenses are explicitly crafted to allow forks and redistribution of independently modified copies, but in this particular case, the fact that Hackage names are first-come-first-serve, and (by default at least) reserved on a personal title, means that authors can effectively designate their own version as the “blessed” one, and even if everyone else agrees to move to another fork, it won’t change the “blessed” status. Now, I’m not saying that “dispossessing” Hackage names should be done lightly; but in cases like these, where the original maintainers have clearly stated to not be willing to cooperate in any way, it would be the least evil. Forking `basement` under a different name would come with serious issues - `basement` has over 4000 indirect dependencies, and I suspect that many of them have version bounds along the dependency chain that would require releasing new versions of not just the direct dependencies, but also most of those indirect dependencies. Given the sheer number of those packages, such an effort could take months, maybe years, and in the meantime, anyone who is affected by `basement` bitrot will have to stick to old GHC versions and outdated versions of many packages. And due to the way dependencies work in Haskell, this could even lock people into outdated versions of packages that don’t depend on `basement` at all: if, due to these shenanigans, you have to stick with an older GHC release, many newer packages simply won’t work anymore, and that will then propagate to other packages. Considering some of the quite essential improvements that have happened in the Hackage ecosystem lately (such as moving from cryptonite to crypton, moving towards fixing `FilePath`, etc.), these aren’t just petty concerns; being unable to use up-to-date packages because of shenanigans like these is a full blown security issue.

Hi! I am an enthusiastic user of `xmonad` and I have been following this thread quietly. I have not given up on a Waymonad-like project, but I do admit the outlook appears to be a bit tenuous, to say the least. As it happens to be, we are working on `hs-bindgen`, a tool that can automatically generate (low-level) Haskell bindings to C header files. You may have heard about our recent blog post. In the course of developing `hs-bindgen`, I have been working on a (Nix-focused) tutorial, creating bindings for a small subset of `wlroots` (the backend code). I called the project `hs-wlroots`; I am by no means an expert of `wlroots`, and I have no idea if these bindings are useful to you. But you may be interested in using `hs-bindgen` yourself, probably extending the `hs-wlroots` project. I am happy to help with using `hs-bindgen` or extending `hs-bindgen` so it suits your needs. Cheers!

Thanks! hell is pretty great! I’ve been using it for some years now. This solves a slightly different problem - it’s supposed to run arbitrary Haskell packages and also manage the dependencies. See the example `analysis.md` when in the server spun up by `cabal run sabela-server`. So it’s more similar to a pre-processing step for Jupyter-like notebooks.

And, to go full circle and come back to what stevan said in the beginning: Oleg Grenrus’ plugin Overloaded.Categories actually achieves that to some extent! The trouble is that it’s a GHC plugin and not part of GHC source code. I believe it was too much effort to keep it working after every GHC update, so it bitrotted and doesn’t work beyond 9.0.

Yes and no. First, you cannot straightforwardly reproduce the effects of `ApplicativeDo` with `QualifiedDo`. First, `QualifiedDo` does something very similar like `RebindableSyntax`. It just replaces `>>=` and `pure` etc. with your custom definitions. But it doesn’t change the structure of the desugared `do`-Block, just its building blocks. So `ApplicativeDo` is something quite different (and more complicated) than `QualifiedDo`/`RebindableSyntax` because it really analyses usage and changes the structure of the desugared code. Now, it’s probably easy to generalise `QualifiedDo` to arrows. Already now, `RebindableSyntax` supports arrow notation, but it’s not that useful: The arrow desugaring is very rigid and seemingly has a lot of incidental complexity from tuple packing & unpacking, pre-/postcomposition with certain functions in order to bring everything into the right type signature. I’m not aware of any nontrivial usages of `RebindableSyntax` with arrows, not to the extent to what other have done with monads (like indexed monads etc.). And still, you’re (rightfully) asking whether we can improve the way arrows are desugared. Yes, but it probably takes a bit more than just `QualifiedProc`. We should in the end be able to do e.g. this: procDimap :: Profunctor a => (b -> c) -> (d -> e) -> a c d -> a b e procDimap f g a = proc b -> do d <- a -< f b returnA -< g d This should only require `Profunctor` to work, not `Arrow`. But as of now, `Profunctor` is not even a superclass of `Arrow`. So the first step is implementing a hierarchy proposal similar to the Functor-Applicative-Monad proposal: `Arrow` should have `Profunctor` and `CartesianCategory` as superclasses. Then desugaring should be able to detect those simpler cases where these two superclasses are sufficient, similar to how `ApplicativeDo` works. See: hackage.haskell.org ### (Co)Cartesian categories - Control.Category.Cartesian Minimum definition: hackage.haskell.org ### Overloaded.Categories

This reminds me of Chris Done’s hell language. It has excellent ergonomics (the runner is a standalone binary). It’s explicitly designed as a limited Haskell-reminiscent scripting language, rather than running a GHCi script, so doesn’t support importing extra code that it wasn’t built with. But it might be relevant. (And there’s nothing stopping one from forking to add extra modules & instances.)

TheoH: > I hadn’t encountered the `(<>) <$> <*>` idiom before. Yeah, `f <$> x <*> y` is basically just function application, but where `x` and `y` can be applicatives. And you can extend it for as many arguments as you want: `f <$> x1 <*> x2 <*> x3 <*> x4`. TheoH: > What’s the practical difference between using the straight State monad and the lazy one, here? One gives you the lazy behavior you want and the other has to first compute all the state updates before it can even return one element of the result. I’m not sure about the efficiency. If you want to make sure it is not consuming a linear amount of memory relative to the number of digits, then you need to use either a lazy algorithm or use a manual streaming approach, for example `conduit` or `streamly`, or `bluefin` (from old to new).

The Haskell Foundation’s directors are pleased to announce the nomination process for seats on the Foundation’s board of directors. The Haskell Foundation is a non-profit organization whose mission is to support industrial users of Haskell. The board is the ultimate decision-making body of the Foundation and provides its strategic leadership. It ensures that the Foundation is working toward achieving its mission, and it appoints and supervises senior members of the Foundation’s staff. Following the board membership lifecycle rules, we are announcing four open seats. Directors that have their terms expiring are able to re-apply once for a second term. Due to the flexible board size rules, it is possible that more than four applicants will be selected. We are specifically looking for _active_ board members who are interested in helping with Haskell Foundation activities such as, but not limited to: * Establishing and maintaining relationships with industrial (and academic) users of Haskell. * Helping with fundraising. * Talking to developers of various Haskell projects and working groups. * Running or organising events. Part of being a board member is a commitment to participate actively in Haskell Foundation activities, outside board meetings themselves. It is hard to quantify, but you should think in terms of devoting a few hours each week to the Foundation. ## The Foundation Board ### Membership * Being a director of the Foundation gives you the opportunity to contribute directly to its strategic direction, to help build the Haskell community, and to help promote the broader adoption of functional programming. * Once appointed, a director should act in the best interests of the Foundation and the entire Haskell community; they are not appointed to represent only the interests of a particular group. * Being a director is not an honorary role; it involves real work. Directors are expected to serve on, or chair, ad-hoc or permanent working groups, and to contribute to activities such as listed above. * The directors also meet regularly: currently, that is for one hour every two weeks, alternating between UTC 12:00 and 17:00 to accommodate different time zones. Directors may excuse themselves from a meeting, but such excuses must remain infrequent. Low participation may result in the removal of a director from the board. ### Criteria Nominations for membership of the board will be evaluated against the following criteria: * You have a positive drive and vision for the Haskell community and ecosystem. * You have a track record of contribution to the Haskell community and ecosystem * You are widely trusted and respected in the community. * You have enough time and energy to devote to being a member of the board. * You have a willingness to engage with the wider community, especially industrial users of Haskell. The Foundation is committed to supporting and representing enterprises and individuals who use Haskell to deliver products and services. The Foundation’s board also aims to reflect the priorities of other Haskell constituencies, including: * Companies that use Haskell in production, and Haskell consultancies. * Users of Haskell. That might include companies, but also includes the broader open-source community and hobbyists. * Sponsors: companies (or even individuals) who are funding the Foundation. * People who build and run the infrastructure of the Haskell ecosystem (e.g. compilers, libraries, packaging and distribution, and IDEs). * Educators, including school, university, and commercial training courses. * Functional programming researchers who build on and/or develop Haskell. Nominations are also welcome from people who meet other criteria but do not represent any particular constituency. Simultaneously hitting all these criteria is nigh impossible. However, each subsequent round of nominations for new board members offers a fresh chance to rectify any imbalances. ### Nominations Please submit your nomination to nominations@haskell.foundation, by March 10th 2026. Your nomination should be accompanied by a brief summary of your qualifications, skills and experiences and a covering letter that says * How you fit the above criteria. * Why you would like to be a board member * What you feel you could contribute For further information about the nomination process, please contact the secretariat of the Haskell Foundation (Secretary Mike Pilgrem and Vice Secretary Michael Peyton-Lebed) at secretariat@haskell.foundation.

While the Generic representation of a data type expresses strictness of constructors/selectors in its Meta data, it appears that the constructors of the representation itself are always lazy, e.g. the two constructors of (:+:). That means that the representation potentially contains more elements than the original type, so that `(from,to)` is an embedding-projection pair rather than an isomorphism. Is that on purpose? Or just the price we pay for not having four variants each of `(:+:)` and `(:*:)`? Consider module Natural where import GHC.Generics data Natural = Zero | Succ !Natural deriving (Show,Generic) bottom :: Natural bottom = Succ bottom s :: Natural -> Rep Natural () s = M1 . R1 . M1 . M1 . K1 -- R1 is lazy, M1 and K1 are strict leq :: Natural -> Rep Natural () -> Bool leq n p = case (from n, p) of (Zero, _) -> True (Succ _, M1 (L1 _)) -> False (Succ n',M1 (R1 (M1 (M1 (K1 p'))))) -> leq n' (from p') We can observe that (Succ Zero) `leq` (s bottom) == True but (Succ Zero) `leq` (from bottom) diverges. Hence `s bottom` is an element of `Rep Natural ()` that is not in the image of `from`.

Basically, yeah. xxxxx

Are the revisions simply adding `buildList` to the default implementation of `OverloadedLists`, and specifying how it works when `RebindableSyntax` is on?

Probably not, I’m currently focused on merging qualified strings, and then getting string interpolation in. But if anyone else wants to pick it up, it should be close to the finish line, after some recommended revisions