3 ms·

Can you give me an example of a Haskell expression which isn't reverentially transparent (without unsafePerformIO)? > An expression is called referentially tra

Can you give me an example of a Haskell expression which isn't reverentially transparent (without unsafePerformIO)? > An expression is called referentially transparent if it can be replaced with its corresponding value (and vice-versa) without changing the program's behavior. ^ that is the definition of referential transparency I am aware of. You seem to be implying that FPers have bastardized the term through their misunderstanding. But the bog standard FP definition is a real and useful concept. Maybe it stole something else's name? But I don't think it's due to being mistaken. Because the FP concept itself is pretty rigorous.

pron 3y ago
> Can you give me an example of a Haskell expression which isn't reverentially transparent (without unsafePerformIO)? Yes: https://github.com/ncaq/debug-trace-var https://github.com/ncaq/debug-trace-var The trick, however, is not unsafePerformIO (destructive mutability has nothing to do with referential transparency in general, although it breaks it in Haskell specifically) but with TemplateHaskell, as quoting has everything to do with referential transparency. > But the bog standard FP definition is a real and useful concept. Actually, it's rather tautological. It defines FP circularly (see my comment here: https://news.ycombinator.com/item?id=36152488 https://news.ycombinator.com/item?id=36152488). It says nothing more than the far more useful explanation: "the meaning of every expression is a value".
- whateveracct 3y ago
  hm okay so basically anything that doesn't use TH or unsafePerformIO is gonna be referentially transparent. And TH is even deferentially transparent at TH-time. It only "breaks it" when evaluating the whole program. But each "stage" maintains the property. I'm assuming any pure language with macros is also r.t. at each stage and only pedantically breaks r.t. when combined. But I don't think that especially hurts the ability to do fast and loose reasoning so long as the core language is pure. It definitely doesn't seem correct to say Java is more referentially transparent than Haskell here. You don't have to go into such niches in Java to lose that property.
  - pron 3y ago
    > You don't have to go into such niches in Java to lose that property. It's not so easy. You'd have to examine debugging information in stack traces and use reflection. You can't write such a "trace" operator in Java or in Zig. Of course, without macros, C is almost perfectly referentially transparent and Haskell is, too (except for unsafePerformIO).
    - whateveracct 3y ago
      You can also mutate a list that is passed in and suddenly you cannot do substitution to reason about your program.

pron 3y ago

> Can you give me an example of a Haskell expression which isn't reverentially transparent (without unsafePerformIO)? Yes: https://github.com/ncaq/debug-trace-var https://github.com/ncaq/debug-trace-var The trick, however, is not unsafePerformIO (destructive mutability has nothing to do with referential transparency in general, although it breaks it in Haskell specifically) but with TemplateHaskell, as quoting has everything to do with referential transparency. > But the bog standard FP definition is a real and useful concept. Actually, it's rather tautological. It defines FP circularly (see my comment here: https://news.ycombinator.com/item?id=36152488 https://news.ycombinator.com/item?id=36152488). It says nothing more than the far more useful explanation: "the meaning of every expression is a value".

whateveracct 3y ago
hm okay so basically anything that doesn't use TH or unsafePerformIO is gonna be referentially transparent. And TH is even deferentially transparent at TH-time. It only "breaks it" when evaluating the whole program. But each "stage" maintains the property. I'm assuming any pure language with macros is also r.t. at each stage and only pedantically breaks r.t. when combined. But I don't think that especially hurts the ability to do fast and loose reasoning so long as the core language is pure. It definitely doesn't seem correct to say Java is more referentially transparent than Haskell here. You don't have to go into such niches in Java to lose that property.
- pron 3y ago
  > You don't have to go into such niches in Java to lose that property. It's not so easy. You'd have to examine debugging information in stack traces and use reflection. You can't write such a "trace" operator in Java or in Zig. Of course, without macros, C is almost perfectly referentially transparent and Haskell is, too (except for unsafePerformIO).
  - whateveracct 3y ago
    You can also mutate a list that is passed in and suddenly you cannot do substitution to reason about your program.