3 ms·

"Even a side-effecting function call in C has a well-defined "value" as a state transformer that maps states to pairs of states and values (the so-called "monad

"Even a side-effecting function call in C has a well-defined "value" as a state transformer that maps states to pairs of states and values (the so-called "monad" in functional programmers' terminology). The reluctance of functional programmers to call such languages "referentially transparent" merely implies that they are reluctant to admit such complex mathematical/conceptual objects as "values". On the other hand, they seem perfectly willing to call a state transformer a "value" when it is put in their own favourite syntax and dressed up with a buzz word like "monad". I have to say that they are being entirely inconsistent, even if we grant it to them that their idea of "referential transparency" has some coherence." http://stackoverflow.com/a/11740176 http://stackoverflow.com/a/11740176

tel 12y ago
I don't think people who really understand referential transparency would claim that it's impossible to give C a referentially transparent semantics. It's pretty easy. (This essentially feels like looking at the meaning of the language from "the inside" versus "the outside" if that makes sense.) There's a difference between being able to imagine such a semantics and having that semantics be in common and widespread use or having it be useful to explain functions of the language or common techniques. The nice thing about, e.g., Haskell is that these referentially transparent semantic models are really just shoved into your face. Purity makes it hard to ignore referential transparency. Monads make it incredibly clear when you have regions of code which aren't referentially transparent. So, much like the whole contentious "vacuous type system" arguments from a day ago---these analyses exist naturally for practically any language you can think of but their value varies a lot depending on whether or not they are natural.
- l_dopa 12y ago
  I think this is somewhat misleading. It's easy to give a semantics for a toy C-like imperative language. As far as I know, a semantics that is mostly faithful to the C standard becomes extremely complicated and requires modeling e.g. code layout in memory. The equational reasoning you get from that kind of semantics is terribly weak: essentially, only terms that have the same byte-for-byte effect on memory are really equivalent. So I wouldn't say that exploiting "referential transparency" in Haskell is somehow more obvious, but that it's useful at all.
  - tel 12y ago
    I think we're in agreement on content if not tone... and, honestly, I think your tone is probably closer to reasonable while mine was a bit facetious. I said it that way to emphasize the argument that existence of a referentially transparent semantics isn't enough, though. You need extant and useful.
    - AnimalMuppet 12y ago
      Very true. In fact, that's true of every language feature. Way too often, people waste time bikeshedding about how language X can do Y. But if it can't usefully do it, who cares?
Dewie 12y ago
You might as well say that any language takes as input The Universe and returns a new Universe (perhaps also adjusting for time, if the program gives output during the execution). See? Totally referentially transparent. But not interesting. Like he says, the technique/viewpoint is already known in FP. But in certain languages you have more control over it than others.
deleted 12y ago
[deleted]
bad_user 12y ago
The value in a monad is that it allows you to work with pure data transformations (functions), which can then be reused, composed, tested, used in isolation and then deal with the side-effect later when you really need it. If you think about the monadic type as a container, it allows you to apply transformations while not pulling the values out of that container (think data-structures). If you think about a monad as a context, it allows you to apply transformations while keeping the context (think Future/Promise). The call of a side-effecting function of course it has a well-defined value and I don't think there's anybody knowledgeable enough in FP to deny that. Problem is - there's data missing in the representation of side-effecting operations. For example, take a statement like this: x = x + y As a matter of fact, this makes no sense mathematically, because there's data missing from the above representation, as it really means this (where i, j and k are moments in time): x(i) = x(i - j) + y(i - k) So time is actually an implicit parameter here that you've got no control over. The above representation makes even more sense when studying the architecture of CPUs. And as a side-effect, the old value of "x" gets lost and so if anybody else holds a reference to "x", then that reference will point to an entirely different value, an event that can happen at arbitrary points in the future, so you could say that the whole world changes after an operation like that. Since concurrency is often brought into the picture, I think it's fairly easy to see how this can create problems in terms of our capability to reason about the logic we read or write. Also, if we think about side-effecting components (say, mutable objects), the functional behavior of such a component ends up depending on its history, history that's in no way explicit. Variables are buckets or places. Immutable values are facts that can be compared. E.g. 2 references to mutable things cannot be considered equal, unless they point to exactly the same memory location, otherwise equality (as defined in the programming languages we are using) is broken and a constant source of gotchas. That link you posted argues that the way we are using the term "referential transparency" today for programming languages is different from its original meaning, but I'm arguing that the original meaning is not relevant for programming languages. There's no point in arguing that a side-effecting function call in C does have a well-defined "value". Yes, the output of a side-effecting function can be considered a value, but you can't treat it as a value. Of course, we can always argue semantics.

tel 12y ago

I don't think people who really understand referential transparency would claim that it's impossible to give C a referentially transparent semantics. It's pretty easy. (This essentially feels like looking at the meaning of the language from "the inside" versus "the outside" if that makes sense.) There's a difference between being able to imagine such a semantics and having that semantics be in common and widespread use or having it be useful to explain functions of the language or common techniques. The nice thing about, e.g., Haskell is that these referentially transparent semantic models are really just shoved into your face. Purity makes it hard to ignore referential transparency. Monads make it incredibly clear when you have regions of code which aren't referentially transparent. So, much like the whole contentious "vacuous type system" arguments from a day ago---these analyses exist naturally for practically any language you can think of but their value varies a lot depending on whether or not they are natural.

l_dopa 12y ago
I think this is somewhat misleading. It's easy to give a semantics for a toy C-like imperative language. As far as I know, a semantics that is mostly faithful to the C standard becomes extremely complicated and requires modeling e.g. code layout in memory. The equational reasoning you get from that kind of semantics is terribly weak: essentially, only terms that have the same byte-for-byte effect on memory are really equivalent. So I wouldn't say that exploiting "referential transparency" in Haskell is somehow more obvious, but that it's useful at all.
- tel 12y ago
  I think we're in agreement on content if not tone... and, honestly, I think your tone is probably closer to reasonable while mine was a bit facetious. I said it that way to emphasize the argument that existence of a referentially transparent semantics isn't enough, though. You need extant and useful.
  - AnimalMuppet 12y ago
    Very true. In fact, that's true of every language feature. Way too often, people waste time bikeshedding about how language X can do Y. But if it can't usefully do it, who cares?

Dewie 12y ago

You might as well say that any language takes as input The Universe and returns a new Universe (perhaps also adjusting for time, if the program gives output during the execution). See? Totally referentially transparent. But not interesting. Like he says, the technique/viewpoint is already known in FP. But in certain languages you have more control over it than others.

deleted 12y ago

[deleted]

bad_user 12y ago

The value in a monad is that it allows you to work with pure data transformations (functions), which can then be reused, composed, tested, used in isolation and then deal with the side-effect later when you really need it. If you think about the monadic type as a container, it allows you to apply transformations while not pulling the values out of that container (think data-structures). If you think about a monad as a context, it allows you to apply transformations while keeping the context (think Future/Promise). The call of a side-effecting function of course it has a well-defined value and I don't think there's anybody knowledgeable enough in FP to deny that. Problem is - there's data missing in the representation of side-effecting operations. For example, take a statement like this: x = x + y As a matter of fact, this makes no sense mathematically, because there's data missing from the above representation, as it really means this (where i, j and k are moments in time): x(i) = x(i - j) + y(i - k) So time is actually an implicit parameter here that you've got no control over. The above representation makes even more sense when studying the architecture of CPUs. And as a side-effect, the old value of "x" gets lost and so if anybody else holds a reference to "x", then that reference will point to an entirely different value, an event that can happen at arbitrary points in the future, so you could say that the whole world changes after an operation like that. Since concurrency is often brought into the picture, I think it's fairly easy to see how this can create problems in terms of our capability to reason about the logic we read or write. Also, if we think about side-effecting components (say, mutable objects), the functional behavior of such a component ends up depending on its history, history that's in no way explicit. Variables are buckets or places. Immutable values are facts that can be compared. E.g. 2 references to mutable things cannot be considered equal, unless they point to exactly the same memory location, otherwise equality (as defined in the programming languages we are using) is broken and a constant source of gotchas. That link you posted argues that the way we are using the term "referential transparency" today for programming languages is different from its original meaning, but I'm arguing that the original meaning is not relevant for programming languages. There's no point in arguing that a side-effecting function call in C does have a well-defined "value". Yes, the output of a side-effecting function can be considered a value, but you can't treat it as a value. Of course, we can always argue semantics.