@BurningWitness, I completely disagree! Point by point
I don’t believe this is a language problem, but instead a failure to reason about code correctly on programmer’s part
I don’t think it’s a language “problem” either. However, I want programmers to not to have to reason about code when that reasoning can be done automatically by the machine! That’s why I use Haskell in the first place and why I value “making invalid states unrepresentable”.
You can’t “fix” laziness in Haskell
I don’t want to “fix” laziness. I want to make it easier to avoid programming mistakes that are easy to make due to laziness being the default.
you can only create a library that defines a new set of arcane rules
I’m not sure what “arcane rules” you are referring to. By “a library” are you referring to strict-wrapper? If so I would deny that it defines “arcane rules”! Quite the opposite. It is extremely simple and only requires familiarity with pre-existing, basic, Haskell concepts.
fighting an uphill battle both against the syntax (if it’s so important, why isn’t it a part of the language?)
One of the things that is wonderful to me about Haskell is that so many things can be libraries rather than having to be baked in to the language. In fact, that’s one of the benefits we get from laziness by default!
and the programmer (who isn’t learning about laziness, they’re learning your library).
I don’t really follow why that’s part of an uphill battle … In any case, I love it when libraries prevent the need to learn hard concepts! (For example, that’s why STM is so wonderful.) But I don’t think strict-wrapper stops a programmer from needing to learn about laziness. But it does mean that she doesn’t have to remember to apply that knowledge in each relevant situation. She is instead prompted to apply it by the type system. That’s exactly what I love about Haskell.
The problem I see is paranoia, people getting the wrong impression that the language was designed wrong and that they have to use one of the libraries to shield themselves from the harmful influence of thunks.
I’m sorry if you got the impression that I’m paranoid about laziness or that I think the language was designed wrong. That’s not what I think at all.
In my experience I’ve only run into a large space leak once in like four years, stemming directly from the fact that I didn’t know what I was doing and it was solved with just a few bang patterns.
You’re very lucky! In my professional use of Haskell I have come across many space leaks written by well-known Haskellers who you have likely heard of, some of which caused gigabytes of extra memory residency. For example, megaparsec is one of the most widely-used parser libraries. It had a space leak that almost every user will have hit (until I fixed it).
It’s an unfortunate rule for other reasons too, for example it rules out Coercible ValidatedEmailAddress String and other similar "newtype with smart constructor" approaches to type safety.
