Consider that IO includes exception-handling

IO also includes concurrency, which is even more troublesome.

Conal, nice observation about Landin. I have to say “denotative” is an appealing term.

I suppose the correct phrase should be “side effect free functional programming”

Oh well…

One could say that Haskell IO expressions “denote something” but we don’t quite know what ….

Though I doubt that IO does denote anything, given the requirement of compositionality of semantics. Consider that IO includes exception-handling, which is sensitive to order-of-evaluation of pure (non-IO) expressions. Exception-handling thus extracts more meaning than exists out of pure sub-expressions, breaking compositionality.

Nobody’s mentioned it, but isn’t this what Landin called “denotative”?

Oh — I’d forgotten about Landin’s use of “denotative”. Thanks for the reminder.

From section 8 of The Next 700 Programming Languages:

The commonplace expressions of arithmetic and algebra have a certain simplicity that most communications to computers lack. In particular, (a) each expression has a nesting subexpression structure, (b) each subexpression denotes something (usually a number, truth value or numerical function), (c) the thing an expression denotes, i.e., its “value”, depends only on the values of its subexpressions, not on other properties of them.

It is these properties, and crucially (c), that explains why such expressions are easier to construct and understand. Thus it is (c) that lies behind the evolutionary trend towards “bigger righthand sides” in place of strings of small, explicitly sequenced assignments and jumps. When faced with a new notation that borrows the functional appearance of everyday algebra, it is (c) that gives us a test for whether the notation is genuinely functional or merely masquerading.

Then in section 9:

An important distinction is the one between indicating what behavior, step-by-step, you want the machine to perform, and merely indicating what outcome you want. Put that way, the distinction will not stand up to close investigation. I suggest that the conditions (a-c) in Section 8 are a necessary part of “merely indicating what outcome you want.” The word “denotative” seems more appropriate than nonprocedural, declarative or functional. The antithesis of denotative is “imperative.” Effectively “denotative” means “can be mapped into ISWIM without using jumping or assignment,” given appropriate primitives.

I think Landin does indeed mean what I mean. I’m uncertain, as his conditions (b) & (c) say that subexpressions “denote something”, but he doesn’t say that the something must be explicitly defined. One could say that Haskell IO expressions “denote something” but we don’t quite know what, but then how could we test the claim for validity? What I mean by “denotational programming” requires well-defined, precise and tractable denotations. Those denotations then serve as the basis for implementation correctness, documentation, and formal reasoning.

If I knew that Landin did indeed mean having a precise & tractable denotation, I’d happily adopt his “denotative” in place of my “denotational”. Hm.

I am not sure I understand what this means:

“functional programming has simple, precise semantics” or “functional programming has good compositional properties” or “functional programming is good for reasoning about”.

What would Haskell’s monadic I/O look like if you had what you are thinking about functional?

To the Haskell programmer, it wouldn’t look like anything at all. In other words, the imperative computation would be hidden away in implementations of denotationally defined abstractions. Just as is the case now with imperative computations that implement function call and laziness (stack munging and thunk overwriting).

Can you give a few example of what you can’t defined precisely, what kind of compositional properties are missing, and/or an example of monadic IO program that you can’t reason about.

The early part of Backus’s “liberated” paper discusses these issues with imperative programming. Haskell IO programming is a way to generate imperative computations. Those computations involve system calls, side-effected variables, and loops, just as in Fortran. And they can contain semantically nondeterministic concurrency. Very difficult to reason about precisely.

BTW, his paper on the next 700 programming languages reads in many ways like a description of Haskell

“functional programming has simple, precise semantics” or “functional programming has good compositional properties” or “functional programming is good for reasoning about”.

What would Haskell’s monadic I/O look like if you had what you are thinking about functional? Can you give a few example of what you can’t defined precisely, what kind of compositional properties are missing, and/or an example of monadic IO program that you can’t reason about.

Thanks,

Daryoush