Looking back to that denotative future

[atravers]

The year is 2023. A few brave hackers scour ruins of imperative code, looking for a better way…

ZuriHac 2023

There are other ruins to scour:

Before monadic IO, there was a lot of vibrant and imaginative work on functional I/O. It [just] hadn’t arrived yet […]

The C language is purely functional

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

[atravers]

@hellwolf

Could we at last simply let Haskell/Agda only do the declarative part, and let the runtime written by c++/rust/zig in the imperative language soup to figure out the dirty job of how to actually run them?

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

One way to deal with this is the so called standard solution The purely
functional reduction machine is attached to a von Neumann host machine and an
imperative environment deals with I/O and interactive programs.

Functional programming and the language TALE (page 6 of 88).

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:

• Proposal: "Do notation" syntax - Dhall discussion

• A (failed) attempt at doing IO with Dhall - Dhall discussion

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.

[atravers]

@atravers

[…] 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)

  In this paper we show how, with an appropriate program development environment, it is possible to delay the teaching of I/O until quite late in a first programming course. The result is that the instructor is able to teach the basic concepts of the language and develop the students’ skills to a point where they can write reasonably sized programs before they have to deal with the intricacies of I/O.

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

  Based on our decade-long experience (Felleisen et al. 2004a), novices to programming tend to accept languages that they haven’t heard of — as long as they can quickly construct a program that is like the applications they use on their computers. To this end, the chosen language must come with a rich framework for input and output (I/O), ideally via graphical interfaces. Chakravarty and Keller (2004) present corroborating evidence based on a thorough analysis of their Haskell-based introductory courses.

…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:

(page 13 of 19)

Monadic I/O dates from 1989. Cupitt [5] built a functional operational system (KAOS) in Miranda. He was the first to make large-scale use of types, similar to IO a, for computations returning an answer of type a. […]

Monadic I/O in Haskell 1.3 (1995)

…could the KAOS experiment have been too successful?

[hellwolf]

“imperative core, functional shell”

[atravers]

“imperative core, functional shell”

(heh) …wait a moment:

• Using unsafePerformIO safely? - #70 by atravers

which refers to:

• Using unsafePerformIO safely? - #39 by atravers

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

Here we go again…

C3P0