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

Aren’t all programming languages denotational and it’s only the degree or expressiveness that differentiates one from the other? Isn’t functional programming a specialized subset of denotational semantics?

When I talk about “denotational programming”, I mean an approach to programming, not a language property. So I’m having trouble relating to the question. In denotational programming, all types & operations have precise meanings, given in the style of denotational semantics.

Do you have the reasons why IO doesn’t meet those criteria written up somewhere?

See Backus’s Turing Award lecture, Can Programming Be Liberated from the von Neumann Style? A functional style and its algebra of programs.

I get the clearest understanding by considering the influence of denotational models on reasoning. My experience seems to show that when a data type (or a language) has a simple denotational model, that type is correspondingly easy to reason about, and when the denotational model rings true (compellingly captures the essence of what the type represents), then the programming interface will be correspondingly satisfying to work with.

Now consider the denotational model of Haskell IO. Well, you’ll have difficulty doing so, since we don’t have a denotational model. Consider instead what such a model would be. Remember that IO has thousands of primitives (mostly generated by the foreign-function interface) and nondeterministic concurrency.

Currently we’ve this nice model of pure computations that we can see it’s easily composable, but it doesn’t capture a good deal of what we can do with computers …

I’ve noticed that some folks want programming models to serve the machine, by capturing what the machine can do. I’m more interested in machines as lenses for ideas, i.e., the role of the machine for me is to display ideas for me to observe. I want to express those ideas in a precise & simple way, thus the appeal of denotational design.

my apologies if these are recurring questions too

No problem. I’m getting a sense of what questions to include in a FAQ. Thanks.

Though even what we want to describe is ambiguous, do we want to describe interaction with the current OSes? or some other nicer model? In the latter case, can that model be implemented over current OSes, and will we be able to interoperate with programs written imperatively, or do we need our own separate world?

Though it seems that if we could answer these questions we’d have concluded the research. I guess i’m asking for a more precise formulation of what you’re aiming for.

my apologies if these are recurring questions too