3 ms·

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 prett

by 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?

by tel 12y ago

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?