Mostly constraint inference had changed in subtle ways that completely destroyed the DSL implementation design.
Conversation
Okay, I guess that’s believable, but I feel like writing anything that relies on the subtleties of the constraint solver never, ever changing is probably going to break regardless of your compiler’s approach to backwards compatibility. None of that stuff is guaranteed!
2
2
My snarky comment here is that if the type system isn’t all about guarantees, that significantly diminishes its usefulness. (ghc has also gotten much better in this respect.)
1
1
And if I were to be equally snarky in turn, then I’d say that I think people who attempt to get too fancy with “DSL” design in Haskell deserve to have their programs broken with every GHC release to teach them to knock it off. ;)
2
1
Alexis, I’ve looked up to you since forever, and you’re the last person from which I expect “you’re holding it wrong” defenses :-).
It’s great you have a great workflow, but it doesn’t really help others.
1
Hey, I prefaced it with a disclaimer that I was being snarky! :) Of course I would never actually advocate for such a thing…
…even if maybe sometimes I wish I could…
1
1
I got those vibes from the whole thread (see below), since I’ve seen many complaints these days suggesting otherwise…
Quote Tweet
Replying to @lexi_lambda @samth and @RaeHaskell
Perhaps you don’t fully realize how irrelevant these issues are in Haskell because the tooling makes them trivial to work around. If one of your deps is broken by this, you fork it, delete the /= definition, submit a PR, and add your fork to your build. This takes minutes.
1
I admit that something I have historically been a lot more aggressive about than virtually anything else is the Haskell packaging story, because I legitimately do not understand why people bag on it as much as they do and would frankly love for someone to argue with me about it!
2
2
The new cabal stuff seems to have made it much nicer to work with! There are still packaging related things that make me wary about using Haskell more heavily. I could explain further if you're interested, but I'm more of an outsider and I might be mistaken about some things.
1
1
What do you have in mind?
1
Thinking for example about how (AFAIK) cabal requires single version of a package in a compilation unit. There's tradeoffs around this, but imo it's nicer for gradual upgrades, and leads to less annoyance when you can't install packages due to an incompatible ancestor dependency.
I’m not sure I know what that means, what is the alternative?
2
Show replies