Looking back to that denotative future

There are other ruins to scour:

…they’re just aren’t as easy to find!

1 Like

Actually, some implementations of early functional languages did use that arrangement:

It certainly seems to make sense: at that time, there were very few palatable ingredients for the “imperative language soup” - why would anyone allow that glop to ruin their delectable new declarative or denotative language? Imperativity begone!

But Haskell isn’t arranged in this way. Futhermore, languages which started with that arrangement rarely sustain it e.g. adding support for imperativity like I/O to Dhall have already been contemplated twice:

So the next time anyone suggests that shifting semantically imperative mechanisms out of the programming model and into the implementation is the solution, ask them to explain:

  • why it didn’t work before,

  • and why it should work now.


…particularly with more recent research like this:

  • I/O Considered Harmful (At Least for the First Few Weeks) (1997)

  • A Functional I/O System […] (2009)

…that’s two educational implementations based on strict or eager languages, which at a casual glance seem to use that separation of concerns: the imperative ugliness (of I/O) is the implementation’s problem, leaving students free to focus on their nominated activities.

As for Haskell:

…could the KAOS experiment have been too successful?

1 Like

“imperative core, functional shell”

“imperative core, functional shell”

(heh) …wait a moment:

which refers to:

…note the definition of dfs - functional interface, imperative implementation: