gabby

@fullmoon

she/her

Principal engineer at Mercury. I've authored the Dhall configuration language, the Haskell for all blog, and countless packages and keynote presentations.

I'm a midwife to the hidden beauty in everything.

💖 @wiredaemon

twitch

twitch.tv/GabriellaG439

discord

Gabriella439

discord server

discord.gg/XS5ZDZ8nnp

location

bay area

private page

cohost.org/newmoon

twitter

twitter.com/GabriellaG439

gabby @fullmoon3/6/2024, 10:11 PM

evaluation order in haskell

a thing that I think a lot of people don't quite get about Haskell is that it's actually not lazy evaluation that's the interesting thing about Haskell, but rather that in Haskell evaluation order doesn't matter¹.

In other words, evaluation order becomes an implementation detail that you don't really need to care about. In most programming languages, the order in which things are evaluated changes the order in which side effects are run, but in Haskell that is not the case. That means that the compiler can freely reorder evaluation order and your program outwardly behaves in the exact same way because the order of side effects is completely decoupled from the order of evaluation.

This is easier and slightly well-better behaved in a lazy language like Haskell, but laziness is (in my opinion) not really the key or essential take-away from Haskell. Rather, the key innovation is making evaluation order a concern of the runtime rather than a concern of the programmer.

Modulo infinite loops, a.k.a. "bottoms"

#haskell #functional programming

You must log in to comment.

in reply to @fullmoon's post:

HMPerson1 @HMPerson13/8/2024, 12:54 PM

my understanding is that pure functional programming (where evaluation order does not matter) existed long before Haskell, so in the view of programming language people (and in particular Haskell's creators), Haskell's primary selling point is lazy evaluation.

HMPerson1 @HMPerson13/8/2024, 1:04 PM

notably, under "Goals, principles, and processes:"

Laziness was undoubtedly the single theme that united the various
groups that contributed to Haskell’s design.

An immediate consequence of laziness is that evaluation order is
demand-driven. As a result, it becomes more or less impossible to
reliably perform input/output or other side effects as the result of a
function call. Haskell is, therefore, a pure language.

Once we were committed to a lazy language, a pure one was
inescapable. The converse is not true, but it is notable that in
practice most pure programming languages are also lazy. Why?
Because in a call-by-value language, whether functional or not, the
temptation to allow unrestricted side effects inside a “function” is
almost irresistible.

gabby @fullmoon3/8/2024, 9:44 PM

Yeah, I'm familiar with that paper, and I do understand how Haskell's creators saw things. I'm just saying that I disagree with them and I think purity is the more important reason to use Haskell.

Like, even though purity predates Haskell, Haskell still is the most widely used purely functional language.

Pinned Tags