Hacker News Reader

Comment by teh | Hacker News Reader

I do agree but I also remeber that Haskell is 27 years old. Newer Haskell-inspired languages like PureScript don't have a built-in list any more.

There's a lot of old stuff in Haskell, e.g. String which is a list of char. We have a number of new preludes (base, foundation, protolude, ..) that improve the situation a lot, so I'm not sure we really need a "python 3" moment.

We could definitely be more aggressive in pointing out that you need to use a new prelude though.

View on HN

Any recommendations on which new prelude to use? I'm fairly competent with Haskell but have never looked into these and am feeling decision paralysis -- too many choices.

I've tried a bunch of alternative prelude and my experience is that it makes it very hard to integrate with code that uses the standard prelude. Foundation seems to have the highest chances of success right now, ClassyPrelude seems to be the most well-used, and Protolude seems to be more like a framework to build your own prelude.

I've never understood the hard-to-integrate argument; I can still do `import qualified Prelude as P`.

Right, but you need to do explicit conversions between `Foundation.String` and `Prelude.String` at your app's boundaries (for example.)

If you're competent with Haskell, don't bother. A new Prelude will save you a bunch of imports; that's it. If you're fretting over which one to use, you've already spent too much time making this decision; just stick with the regular Prelude and use your imports.

The worst thing about the default Prelude is that it encourages bad behavior among new users--for instance, with partial functions like `head`. Experienced people know what to avoid and what to work around. So if picking an alternative Prelude seems like too much work, it is.

I have a project where I have mostly dumped the Prelude. All it is doing is saving me a bunch of imports. That's nice but not earth-shaking.

We're mostly using Protolude at the moment. It has some nice properties, e.g.

* "id" renamed to "identity" so you can use id in your own code

* panic functions like "notImplemented"

* a generic string converter "toS"

* lots more

But to be fair most modern preludes work OK.

Foundation is a bit different in that it doesn't ship a huge amount yet but has the potential to eventually replace the core prelude with saner default types like utf8-encoded strings. If you need to ship to production yesterday I would not use Foundation just yet.

Any reason when you don't like String being an alias of [Char]?

The performance is horrible. It does make it very easy to work on strings though.

Assuming you haven't got any complex Unicode, ofc

Everything that's wrong with [] is wrong with [Char] and more so. In a Unicode world, it rarely makes sense to iterate over codepoints in a string, and it's rarely useful to prepend codepoints or drop codepoints at the beginning of a string. Usually an array-like string (e.g. Text) is better; occasionally something like Seq Char might be useful.

>In a Unicode world, it rarely makes sense to iterate over codepoints in a string

I love that people think that being Unicode somehow makes strings into opaque objects that you can never inspect or manipulate. Do you think that strings magically pop into existence fully formed and then magically disappear into a magic box and come out as rendered glyphs on a screen?

I don't disagree that [Char] is a stupid way to represent strings. Strings should very obviously just be byte arrays. Go does it right, it's one of the few things it does right. It turns out the creators of UTF-8 know how to deal with Unicode properly. Who would have thought?

I just mean that inspecting and manipulating strings is sufficiently complex that most of the time you use something like libicu to do it, so the apparent convenience of [] is not useful to the average programmer.

Eh, yeah and no, kinda?

I have no problem with an opaque string type that supports being serialised into bytes. I also have no problem with a string type that exposes the reality that it's internally represented as UTF-8. But I can understand that maybe that's a little imperfect, because you might not want to maintain a perfect normalised correct UTF-8 encoding all the time. e.g. if you concatenate "blahblahlblaha" and the combining acute symbol followed by "blahlbahlblah", you might want to just store them together and normalise them later or something? I don't know.

Reply on news.ycombinator.com