michaelt_

I won't bother to look it up, since it's not important and we probably agree on basically everything, but there were in my memory quite a few tempests in teapots about this sort of thing. It wasn't that there were other working compilers the overt ghc-centrism was dissing; the dispute was more about the desirability of distinguishing the Haskell language from the ghc implementation which pained some. No one doubted that the ghc was the going one, especially once hugs became unmaintained. Among the arguments for overt ghc-centrism were ... that it was confusing to users not to make it obvious that effectively Haskell=ghc. Similarly it was confusing to users ... that there was not something more like a system of standard libraries like those 'blessed' by the Platform. "For commercial adoption we need a clear path through all this stuff, we need clarification, blessing and decision" was one view. I remember people who were disturbed that some Haskell platform pages had you clicking an icon reading "Download Haskell" - meaning the ghc+ Haskell platform. I'd have to hunt for an example but see http://code.galois.com/darcs/haskell-platform/download-websi... for something not quite like that. For someone like dons the fastidiousness that would balk at a "Download Haskell" icon that meant "download ghc+blessed libraries" was ridiculous (rightly, I think, for the time). (Maybe they thought it should yield a pdf of the Haskell Report ...) There were actually quite a few similarities in the arguments, the difference was that no one poisoned the wells in their favor of their side by making up imaginary corrupt commercial motives. The difference was between people with a certain view of how industrial adoption was to be advanced, and a different more language-centric view. There is on reflection quite a bit of similarity between dons and Snoyman

It was almost entirely quotations from you, I guess you can't remember them.

www.haskell.org didn't used to take for granted that ghc is 'the' official haskell implementation. If you look at

https://web.archive.org/web/20090129200859/http://haskell.or...

which immediately lists implementations and compare it to

https://web.archive.org/web/20100402011002/http://www.haskel...

a year later you will be reminded of the rather spectacular struggles that preceded the ghc-centrism of haskell.org . The change was closely associated with the appearance of the haskell platform, and the arguments very similar to those concerning stack and stackage. If you want paranoid theories of corrupt commercial motives in that case, I can produce several incompatible ones for you to choose among.

You said,

> The people involved have been the ones artificially creating the problem by refusing to follow established community standards (the package versioning policy)

and

> The tool does not fix real problems. It avoids a real problem, which the authors of the tool created in the first place. The problem does not exist if packages use upper version bounds. They refuse to, and then release a tool to move people to a curated subset of packages and versions instead, bypassing the problem they've imposed on everyone in the first place.

-- in fact they are no different from e.g. bos and amazonka and many many others; it's a view, we oppose it.

> then they release a tool to "solve" the problem they created, all while spewing FUD about cabal and the actual haskell developers and community.

Again it is demonstrable that they didn't create any problem. And they don't say anything against cabal that thousands of others didn't say. And on and on through your whole chain of nonsense.

Just give it up. They have a view we reject. The solution is to continue to argue against it .. keeping in mind that what we are asking for is torture to maintain even where you are dealing with only 10 external dependencies. It happens that I have just spent basically all morning dealing with dependency problems with four or five pipes-related libraries which keep rigorous upper bounds. Frankly it's unimaginable what yesod or amazonka would have to go through basically every morning with 10-20 times as many other-people's libraries to keep track of. There needs to be some automated way of doing it.

That wasn't your argument at all. I know and constantly affirmed that many people do and have removed upper bounds, and that I myself oppose it. Your 'argument' is the absurd falsification that this practice was introduced to sell BSD3 software that appeared 3 years after the practice was introduced, by a company that appeared over a year after the practice was introduced. What you are doing is unconscionable and destructive.

It's not empty of content, it is devastating to your argument. Check out the upper bounds among these packages http://hackage.haskell.org/user/BryanOSullivan e.g. http://hackage.haskell.org/package/wreq ... there are some, same as there are some for e.g. http://hackage.haskell.org/package/http-client . Not that I approve of this.

It's clear that you weren't around then and don't have the historical knowledge necessary to have a view about this. This isn't stopping you from spreading absurd libels.

The question is historical. I think you can't have been making your immense industrial build in the years immediately preceding `Wed Aug 15 14:54:44 UTC 2012` when `yesod` signed on to Brian O'Sullivan's plan of omitting upper bounds throughout Hackage (a plan which on your view must itself have arisen from O'Sullivan's madness and incompetence or vested interest in a non-existent FPComplete that he never had anything to do with, since there was of course no problem at all, it was just a fiction he cooked up). `yesod`s 2012 act of compliance was on your view calculated by FPComplete (founded 2013) to take over Haskell by means of a then non-existent `stack` tool (2015). On that day, the installation of `yesod`, a perfectly innocent web-related library, required the installation of 145 distinct Hackage packages, as you can verify with a couple of commands. The previous record was held by the pandoc executable which in the form it took on that same fateful day (pandoc-1.9.4.2) required the installation of only 47 distinct packages. Yet in the previous years unlimited amounts of ink had been spilt on the pandoc list and #haskell explaining what was going wrong when pandoc users tried to build the newest version with the feature they had prayed for. With `yesod` things were now completely out of control. This had nothing whatsoever to do with `yesod` or anything else being in itself broken. `yesod` presumably did actually need e.g. `x509-validation` and `aeson-pretty`. Other packages went over to the plan announced by O'Sullivan too, though most of them reverted. --All of this, on your view, was part of a hostile take-over plan by the non-existent FPComplete. You are by the way of course benefitting from stackage in ways you are not recognizing, though, like me, you are not a regular stack user. It is very familiar that before stackage, there was much less coherence among the Hackage libraries. Things were best about one month after a new ghc was released.

You keep repeating the claim that `stack` exists in order to solve a problem deliberately created by the FPComplete crowd. This is frankly a really disturbing lie that has nothing to do with reality or the actual order of events. The theory that upper bounds should be eliminated - which was, I think, no good - is demonstrably independent of the FPComplete people. The theory of extreme restriction of bounds, the theory of eliminating upper bounds, and the existence of stack, stackage and so on are founded on real and genuine problems that arose with the appearance of immense builds like pandoc and especially yesod. I didn't particularly care for the stack business when it came along, but this is because I understood `cabal-install` pretty well, and still prefer it, but more importantly because I wasn't engaged in professional development that involved the co-operation of e.g. 100 Haskell packages - though I did spend countless hours helping new users get around the build problems with yesod and the like. It just is a fact that `cabal-install` was not ready for the existence of the phenomenon of the immense industrial Haskell build.

This totally rewrites history. The idea of scrapping upper bounds was introduced by Brian O'Sullivan https://mail.haskell.org/pipermail/haskell-cafe/2012-August/... whereupon it was adopted by yesod as you can see by comparing http://hackage.haskell.org/package/yesod-1.1.0 (before bos's verdict) and http://hackage.haskell.org/package/yesod-1.1.0.1 (after bos's verdict). If you study the cabal file for yesod 1.1.0 you will see that the method it employed then was extreme restriction of constraints. I don't use stack all that much, and certainly disapprove of omitting upper bounds, but the truth is, it was a chamber of horrors to get really large complex builds to work in those days. pandoc and yesod in particular were really hopeless, and one was constantly explaining to beginners how to get these things to work. Now these problems don't arise; if you are building something that will require 50 libraries to be installed, of course you use stack.