I was pointed to your article from haskell-cafe where a real world instance of the horrible Int semantics resulted in the same program mysteriously behaving differently on two different platforms.

My only “contribution” here is to question the premise that led The Committee to give Int the silent overflowing semantics. With modern compiler technology and modern hardware, trapping overflows doesn’t necessarily come with a larger performance overhead. A conditional branch on the overflow from an add is nearly zero cost as it predicts perfectly and can be issued in parallel with all other instructions. Some architectures, eg. SPARC, even have overflow checking add/sub variants with zero overhead. Not to mention that for many instances it’s trivial to see that overflow can’t happen.

From your original post, you seemed to be saying: “I don’t like System.Info.os :: String” since that violates (the soul of) RT. […]

I think I see part of the communication gap here: you thought my post was talking about referential transparency. Instead, I was shifting the conversation away from a focus on RT and onto two other principles. With the first one (“the value of a closed expression … depends solely on the expression itself”), I made a passing nod to RT, accidentally opening the door to confusion. The second one, which is “even more fundamental to me”, is that types have meanings, and the meaning of an expression belongs to the meaning of type of that expression.

One reason I’d like to reframe these discussions in terms other than RT is that I repeatedly see RT discussions get terribly muddled. And for me, the definitions of RT are technical and without heart. I get a lot more clarity and oomph out of the principles I’ve stated in this blog post.

Here’s a more accurate reading of what I was trying to convey: “I don’t like System.Info.os :: String since that typing violates these two principles that are at the heart of what I love about functional programming. And, by the way, those principles are at the heart of RT for me as well.” Because there’s so much confusion about RT, and it’s such a technical/lifeless notion, I’m offering a hopefully-more-fruitful alternative to RT as a framework for discussing notions of purity.

Since I think we might be talking past each other, at this point I think we might be better hashing this out over IRC sometime. Btw, I’m enjoying this discussion and I think it’s all very interesting!

I’m delighted & relieved to hear you’re enjoying the discussion. It’s so hard to tell without the usual non-verbal cues, so thanks for letting me know. I’ll be happy to chat more on IRC.

First, I’m picking up something of a bait-and-switch going on here (unintentional, I presume). I didn’t say that getStr is RT (referentially transparent), nor that I was giving a definition of RT.

Ok, maybe I am confused here. From your original post, you seemed to be saying: “I don’t like System.Info.os :: String” since that violates (the soul of) RT. Then I suggested that making its type IO String doesn’t seem to fix anything, also that according to (what I thought was) your definition of RT, getStr was not RT either. From your response I got the (erroneous?) impression that you thought that yes, if we make Info.os :: IO String then we’re RT. Likewise for getStr.

Since I think we might be talking past each other, at this point I think we might be better hashing this out over IRC sometime. Btw, I’m enjoying this discussion and I think it’s all very interesting!

The pure lambda calculus — just abstraction and application — is completely RT. Every symbol must have a definition (it is equivalent to a program where every “symbol” is bound by a lambda). The very second you add something new — numbers/addition, booleans/if-then-else — it’s likely you have introduced symbols with no definition. They don’t necessarily break RT, that term just doesn’t mean anything for those symbols.

Hmm. “… without affecting semantics” was an interesting phrase in my definition. Expressions have many types of semantics, all acting at once. So when we talk about RT, we must do so with respect to some given semantics. Eg. we might be able to say that Haskell (sans IO, FFI, and seq) is RT wrt. its domain-theoretic semantics. But certainly it is not wrt. its (say, GHC’s) operational semantics, because definitions introduce sharing.

I think it would be more useful if you would just give your argument as to why getStr is still RT according to your definition rather than trying to use the socratic method over this comment thread.

First, I’m picking up something of a bait-and-switch going on here (unintentional, I presume). I didn’t say that getStr is RT (referentially transparent), nor that I was giving a definition of RT.

It was you, not I, who claimed that getStr is RT. I wouldn’t make a claim either way, because I don’t know what RT can mean for IO.

Usually referential transparency is defined as meaning that a subexpression can be replaced by its value without change in meaning. This definition is problematic in general, since expressions and values are different sorts of things. Some types have a sort of normal form, which could be considered “values”. For instance, for numeric types, we have numerals/literals. For IO in particular, I don’t know what plays the role of “literals”.

Another definition of referential transparency is that any subexpression can be replaced by another expression that has the same value/semantics, without changing the meaning/value of the containing expression. Again there’s some subtlety. When we say that two (sub)expressions do or do not “have the same value”, what do we mean by “same”? For the statement to be meaningful, we have to define semantic equality. I don’t know of such a definition for IO. Perhaps a compelling definition could exist, but perhaps not.

IO carries the collective sins of our tribe, as the scapegoat did among the ancient Hebrews. Or, as Simon Peyton Jones expressed it, “The IO monad has become Haskell’s sin-bin. Whenever we don’t understand something, we toss it in the IO monad.” (From Wearing the hair shirt – A retrospective on Haskell.) Is it likely that we can then come along later and give a compelling and mathematically well-behaved notion of equality to our toxic waste pile? Or will it insist on behaving anti-sociably, as our own home-grown Toxic Avenger?

Paul continues:

Let me give my argument as to why getStr (and other functions that have side effects) is RT. I think I have a more limited definition of RT: to me, a RT function is one with the property that any call to it can be replaced with its result without affecting the semantics of the program. I think of this as dictating that the function must have all its behavior reflected in its return value – there is not other way for it to propagate information to the rest of the program. It means that you can reason about program behavior by simple substitution – just replace each function call with the value that call refers to.

First, I’d simplify/generalize away the role of functions here, and talk about expressions (including function applications) rather than functions as RT. Something of a nit-pick I realize, but I don’t know how else to get to clarity (and beyond opinions) on issues like this one. As David R. MacIver said in “A problem of language“,

Of course, once you start defining the term people will start arguing about the definitions. This is pretty tedious, I know. But as tedious as arguing about definitions is, it can’t hold a candle to arguing without definitions.

Since “getStr” is not a function but is an expression, we’ll probably want a definition that applies to expressions.

Next, there are the troubling (to me at least) questions I raised above: What is the value of an IO sub-expression? How could such a value be substituted into a program? What does it mean to say whether or not the meaning of new expression is equal to the meaning of the old expression?

Continuing,

Since Haskell forces you to thread a single IO value through all functions that perform IO, there is no way for the program to detect that values of type IO are actually do have side effects. I imagine functions that perform IO as returning a “World” object, which is then passed as an argument to the next function that performs IO, which returns a new World object, etc. We can pretend that the IO values that are chosen dynamically were in fact chosen ahead of time, before we even ran our program.

I’ve read and re-read this paragraph, trying to sort it out, particularly how you’d believe that “Haskell forces you to thread a single IO value through all functions that perform IO” or that “values of type IO are actually do have side effects”.

My best guess is that you’re confusing “IO values” with the hypothetical World values that GHC uses in its implementation of IO, and confusing “functions that perform IO” with IO values themselves. I don’t know whether the confusion is in your language or your thinking, or whether I’m just somehow missing what you’re saying here.

By the way, GHC’s World-passing representation of IO is just an implementation hack. It’s not a sound denotational model of Haskell IO, because it cannot account for concurrency. It somehow became popular to think that the World type was something more than an implementation hack.

There is a popular, and much simpler, argument about the referential transparency of IO in Haskell, which I think is very different from what you’re saying. In this perspective, the reason that “there is no way for the program to detect that values of type IO are actually do have side effects” is simply that they honestly do not have side-effects. No lie necessary. IO values don’t do anything; they simply are. It is only a particular interpretation of those values that gives rise to side-effects. Sometimes people get confused about this distinction or think it’s some kind of strange magic or con game. I liken it to the situation with simple types like Boolean and Integer. The values denoted by “True” and “3+4″ have no side-effects, and yet the interpretation called “print” will indeed lead to a side-effect.

Thus, many claim, IO in Haskell is a well-behaved, purely functional type, and Haskell’s chaste status as purely functional is preserved. I’m not a big fan of this line of thought. As I explained elsewhere, similar reasoning shows that The C language is purely functional.

While this viewpoint avoids disproving referential transparency IO in Haskell, it doesn’t demonstrate referential transparency, because our definitions of referential transparency depend on equality, and we don’t have a definition of equality for IO. Maybe we can come up with a sound and compelling definition that is consistent with concurrency and with everything tossed into the sin-bin so far and yet is somehow sound and compelling.

I think it would be more useful if you would just give your argument as to why getStr is still RT according to your definition rather than trying to use the socratic method over this comment thread.

Let me give my argument as to why getStr (and other functions that have side effects) is RT. I think I have a more limited definition of RT: to me, a RT function is one with the property that any call to it can be replaced with its result without affecting the semantics of the program. I think of this as dictating that the function must have all its behavior reflected in its return value – there is not other way for it to propagate information to the rest of the program. It means that you can reason about program behavior by simple substitution – just replace each function call with the value that call refers to.

Since Haskell forces you to thread a single IO value through all functions that perform IO, there is no way for the program to detect that values of type IO are actually do have side effects. I imagine functions that perform IO as returning a “World” object, which is then passed as an argument to the next function that performs IO, which returns a new World object, etc. We can pretend that the IO values that are chosen dynamically were in fact chosen ahead of time, before we even ran our program.

You said of RT: “the value of a closed expression (one not containing free variables) depends solely on the expression itself — not influenced by the dynamic conditions under which it is executed.”

By this definition, even getStr :: IO String is not RT, since its value clearly depends on the dynamic conditions under which it is executed. Likewise if you change System.Info.os to return IO String.

Does the value of getStr depend on dynamic conditions? How can you tell? What do you mean when you say that one action (IO value) is the same as or is different from another action?

One thought I had is that it may be better to think of a Haskell program as not being fully closed – that is, there are certain free variables that are bound only when executing a Haskell program on a particular machine. For instance, the functions specifying the details of Int arithmetic could be considered free variables in a Haskell program. When we decide to run a Haskell program on some specific system, what we are really doing is supplying values for these free variables and running the resulting closed expression.

I get a queasy feeling about this suggestion. I worry about arbitrariness sneaking in to our semantic model. Why bind variables when assigning Haskell code to a particular machine? Why not bind whenever processing changes threads or cores? Or hours? The meaning of my code could change every hour, on the hour. Or moment-to-moment, as in consistently non-RT languages. Moreover, consider distributed execution, as mentioned previously in comments.
I really do believe that intelligently transient distributed execution will become the norm. And functional languages could be ready unless we make some semantically incautious choices and fail to fix the ones we’ve already made.

Besides, functional languages already have an elegant and semantically sound way to express values that depend on dynamic information: functions. If we want code that depends on choice of OS, machine bit width, or time of day, I’d be a lot more comfortable defining functions over arguments of those types.