3 ms·

Why are you so quickly assuming that you know better what I mean than I do? Could you point out a specific point in my answer that is not compatible / or contr

Why are you so quickly assuming that you know better what I mean than I do? Could you point out a specific point in my answer that is not compatible / or contradcits with the common definition of referential transparency?

kaba0 5y ago
I didn’t mean to assume anything, I just wanted to note that the common definition used in FP circles is not correct. So just exchanging ref. transparency with “not having side effects” in your otherwise perfectly fine and interesting reply will make it correct — since for example Java is also referentially transparent which I guess you would not consider being a pure FP language. (Exchanging a value with a variable referring to the same value will not change the value denoted by the expression for example neither in Java, but it is not too interesting a property in itself)
- valenterry 5y ago
  Sorry, but I find your language inappropriate. > what you mean is simply side-effect freeness This really makes it sound like an assumption. And: > So just exchanging ref. transparency with “not having side effects” in your otherwise perfectly fine and interesting reply will make it correct You implying my answer is incorrect here but you are not giving an example of what is wrong even though I asked for it. That being said, I believe that the definition of referential transparency (and therefore FP) is not useful at all without making "semantics" a part of it. And this is the point where discussion can happen. For example, is the performance characteristics of a function part of the program semantics? I would say no. Even though it matters in practice. Same goes for logging: one can argue that logging (that can not blow up due to e.g. lack of disk space) can be considered irrelevant for program semantics and hence a function that logs something with a "print" can still be pure. If you remove semantics from the definition then the definition becomes rather useless imho. In that case I would rather change its meaning or switch to a different definition alltogether.
  - kaba0 5y ago
    I didn't want to repeat myself as the exact meaning was debated in two threads in this post already, for more details please have a look at them. And I agree, we do have to specify what is the denotation of an expression that shall remain constant after replacing a sub-expression with that part's denotation -- for example choosing value of expression after evaluation is not too interesting, as it is shared by the majority of languages, and can only be "violated" by macros for example. Choosing the denotation as "value and side-effects" doesn't add much over saying simply that the language is pure and as you also note, purity has different levels.
    - valenterry 5y ago
      If you do not point out any contradictions even after being asked twice then I have to conclude that you simply cannot. You could have also referred specifically or quoted the important lines from the other threads, but you did neither. That's not helpful in a discussion. > Choosing the denotation as "value and side-effects" doesn't add much over saying simply that the language is pure You are aware that, regarding the discussion between us two, it was you and not me who even used the term "side-effect" first, right?
      - kaba0 5y ago
        https://news.ycombinator.com/item?id=27415670 https://news.ycombinator.com/item?id=27415670 https://news.ycombinator.com/item?id=27414992 https://news.ycombinator.com/item?id=27414992 > FP means that every expression (= part that can be evaluated) is referential transparent > Referential transparency implies immutability Both of these statements are false. As I said, Java is referentially transparent. addOne(2)’s value is the same as the value of the last line in `var a = 2; addOne(a)`. And Java is most definitely not a pure FP language, and its referential transparency doesn’t imply immutability. You can argue that inserting `int two() { sideEffect(); return 2; }` ‘s invocation in place of 2 will change the semantics of the program but that is precisely the meaning of a side-effecting function — so using referential transparency is redundant in that meaning.

kaba0 5y ago

I didn’t mean to assume anything, I just wanted to note that the common definition used in FP circles is not correct. So just exchanging ref. transparency with “not having side effects” in your otherwise perfectly fine and interesting reply will make it correct — since for example Java is also referentially transparent which I guess you would not consider being a pure FP language. (Exchanging a value with a variable referring to the same value will not change the value denoted by the expression for example neither in Java, but it is not too interesting a property in itself)

valenterry 5y ago
Sorry, but I find your language inappropriate. > what you mean is simply side-effect freeness This really makes it sound like an assumption. And: > So just exchanging ref. transparency with “not having side effects” in your otherwise perfectly fine and interesting reply will make it correct You implying my answer is incorrect here but you are not giving an example of what is wrong even though I asked for it. That being said, I believe that the definition of referential transparency (and therefore FP) is not useful at all without making "semantics" a part of it. And this is the point where discussion can happen. For example, is the performance characteristics of a function part of the program semantics? I would say no. Even though it matters in practice. Same goes for logging: one can argue that logging (that can not blow up due to e.g. lack of disk space) can be considered irrelevant for program semantics and hence a function that logs something with a "print" can still be pure. If you remove semantics from the definition then the definition becomes rather useless imho. In that case I would rather change its meaning or switch to a different definition alltogether.
- kaba0 5y ago
  I didn't want to repeat myself as the exact meaning was debated in two threads in this post already, for more details please have a look at them. And I agree, we do have to specify what is the denotation of an expression that shall remain constant after replacing a sub-expression with that part's denotation -- for example choosing value of expression after evaluation is not too interesting, as it is shared by the majority of languages, and can only be "violated" by macros for example. Choosing the denotation as "value and side-effects" doesn't add much over saying simply that the language is pure and as you also note, purity has different levels.
  - valenterry 5y ago
    If you do not point out any contradictions even after being asked twice then I have to conclude that you simply cannot. You could have also referred specifically or quoted the important lines from the other threads, but you did neither. That's not helpful in a discussion. > Choosing the denotation as "value and side-effects" doesn't add much over saying simply that the language is pure You are aware that, regarding the discussion between us two, it was you and not me who even used the term "side-effect" first, right?
    - kaba0 5y ago
      https://news.ycombinator.com/item?id=27415670 https://news.ycombinator.com/item?id=27415670 https://news.ycombinator.com/item?id=27414992 https://news.ycombinator.com/item?id=27414992 > FP means that every expression (= part that can be evaluated) is referential transparent > Referential transparency implies immutability Both of these statements are false. As I said, Java is referentially transparent. addOne(2)’s value is the same as the value of the last line in `var a = 2; addOne(a)`. And Java is most definitely not a pure FP language, and its referential transparency doesn’t imply immutability. You can argue that inserting `int two() { sideEffect(); return 2; }` ‘s invocation in place of 2 will change the semantics of the program but that is precisely the meaning of a side-effecting function — so using referential transparency is redundant in that meaning.