3 ms·

Referentially transparent means that you can replace an expression with its value without changing the meaning of the program. If everything you can do must be

Referentially transparent means that you can replace an expression with its value without changing the meaning of the program. If everything you can do must be referentially transparent, then that's purely functional programming, because applying functions without side-effects is pretty much the only thing you can do then. Of course, there are some other techniques like rewriting, which strictly speaking are different from purely functional programming, but I consider these two things to be pretty much the same thing.

pron 3y ago
> Referentially transparent means that you can replace an expression with its value without changing the meaning of the program. Not quite. A referentially transparent expression (E) is one where you can replace any of its subexpressions (A) with another (B) that has the same meaning (not value!!!!) as (A) without changing the meaning (not value!!!) of E. However, in purely functional languages, the meaning of any expression is a value, but that's the important thing about them, not the fact that they're referentially transparent as imperative languages equally are. We often use the word "semantics" or "denotation" instead of "meaning" in the above, and we say that a pure functional one is one that has "value semantics", i.e. one where the meaning of an expression is a value. Most programming languages are referentially transparent when not using macros (that was the whole point of talking about referential transparency in programming in the first place), and that's important because it demonstrates both the expressive power and the complexity of macros.
- norir 3y ago
  Do you have sources for your definition? The original definition that I'm finding from Quine seems to broadly support the interpretation that an expression is referentially transparent if it can be replaced by its value without altering program semantics, as others have stated. Regardless, it isn't clear to me how macros are any more or less referentially transparent than function calls in an impure language.
  - whateveracct 3y ago
    I'm very sure the commenter is being a little pedantic But even pedantry can't argue that Java is a fundamentally more referentially transparent language than Haskell lol. That threw me for a loop.
    - pron 3y ago
      Right, the incorrect and quite pointless common use of "referential transparency" in FP fan circles tends to throw people off when they first see and understand the actual meaning of the term.
      - whateveracct 3y ago
        Well it's not pointless. The term as used in FP has a pretty well-defined meaning [1] and it is a quality only some programs have. And a program having that quality enhances (fast-and-loose) equational reasoning. [1] I can point at most Java code and prove how it fails the definition. It's not especially hand-wavey.
  - pron 3y ago
    The thing that is preserved is "meaning" or "referent" -- the term Quine uses (hence, "reference transparency") -- not "value". The distinction between referent/meaning and value is the most important aspect of distinguishing between pure FP programming languages and others, and yet that's the thing that is so commonly confused by FPers using the terminology, which makes it quite pointless. In most programming languages the reference or meaning of a term is not a value; in pure functional languages the meaning is a value and that's what makes them special, not their referential transparency which they share with imperative languages. Here's an example from C: int global_x = 0; void f() { x++; } void g() { x++; } f and g have the same meaning in C (but the function `void h() { x += 2; }` does not) yet `m(f)` and `m(g)` will not have the same meaning if M is defined as: #define m(x) #x However, f and g are interchangeable anywhere else (this is not actually true because their addresses can be obtained and compared; showing that a C-like language retains its referential transparency despite the existence of so-called l-values was the point of what I think is the first paper to introduce the notion referential transparency to the study of programming languages: https://github.com/papers-we-love/papers-we-love/blob/main/languages-theory/fundamental-concepts-in-programming-languages.pdf https://github.com/papers-we-love/papers-we-love/blob/main/l... You may be surprised to see that Strachey also uses the word "value" but his point later is that value is not what you think it is)
- auggierose 3y ago
  Do you have a pointer to a paper where "referentially transparent" is defined in your sense? I grant you that values of a programming language should be distinguished from the meaning of an expression, which will be a value of some sort in the logic. In that sense, any language with a denotational semantics will be referentially transparent. So maybe what you are really saying is: macros usually don't have a denotational semantics. Not sure that it is helpful to call this referential transparency, because it differs from the meaning most people associate with it.

pron 3y ago

> Referentially transparent means that you can replace an expression with its value without changing the meaning of the program. Not quite. A referentially transparent expression (E) is one where you can replace any of its subexpressions (A) with another (B) that has the same meaning (not value!!!!) as (A) without changing the meaning (not value!!!) of E. However, in purely functional languages, the meaning of any expression is a value, but that's the important thing about them, not the fact that they're referentially transparent as imperative languages equally are. We often use the word "semantics" or "denotation" instead of "meaning" in the above, and we say that a pure functional one is one that has "value semantics", i.e. one where the meaning of an expression is a value. Most programming languages are referentially transparent when not using macros (that was the whole point of talking about referential transparency in programming in the first place), and that's important because it demonstrates both the expressive power and the complexity of macros.

norir 3y ago
Do you have sources for your definition? The original definition that I'm finding from Quine seems to broadly support the interpretation that an expression is referentially transparent if it can be replaced by its value without altering program semantics, as others have stated. Regardless, it isn't clear to me how macros are any more or less referentially transparent than function calls in an impure language.
- whateveracct 3y ago
  I'm very sure the commenter is being a little pedantic But even pedantry can't argue that Java is a fundamentally more referentially transparent language than Haskell lol. That threw me for a loop.
  - pron 3y ago
    Right, the incorrect and quite pointless common use of "referential transparency" in FP fan circles tends to throw people off when they first see and understand the actual meaning of the term.
    - whateveracct 3y ago
      Well it's not pointless. The term as used in FP has a pretty well-defined meaning [1] and it is a quality only some programs have. And a program having that quality enhances (fast-and-loose) equational reasoning. [1] I can point at most Java code and prove how it fails the definition. It's not especially hand-wavey.
- pron 3y ago
  The thing that is preserved is "meaning" or "referent" -- the term Quine uses (hence, "reference transparency") -- not "value". The distinction between referent/meaning and value is the most important aspect of distinguishing between pure FP programming languages and others, and yet that's the thing that is so commonly confused by FPers using the terminology, which makes it quite pointless. In most programming languages the reference or meaning of a term is not a value; in pure functional languages the meaning is a value and that's what makes them special, not their referential transparency which they share with imperative languages. Here's an example from C: int global_x = 0; void f() { x++; } void g() { x++; } f and g have the same meaning in C (but the function `void h() { x += 2; }` does not) yet `m(f)` and `m(g)` will not have the same meaning if M is defined as: #define m(x) #x However, f and g are interchangeable anywhere else (this is not actually true because their addresses can be obtained and compared; showing that a C-like language retains its referential transparency despite the existence of so-called l-values was the point of what I think is the first paper to introduce the notion referential transparency to the study of programming languages: https://github.com/papers-we-love/papers-we-love/blob/main/languages-theory/fundamental-concepts-in-programming-languages.pdf https://github.com/papers-we-love/papers-we-love/blob/main/l... You may be surprised to see that Strachey also uses the word "value" but his point later is that value is not what you think it is)
auggierose 3y ago
Do you have a pointer to a paper where "referentially transparent" is defined in your sense? I grant you that values of a programming language should be distinguished from the meaning of an expression, which will be a value of some sort in the logic. In that sense, any language with a denotational semantics will be referentially transparent. So maybe what you are really saying is: macros usually don't have a denotational semantics. Not sure that it is helpful to call this referential transparency, because it differs from the meaning most people associate with it.