2 ms·

"Telling" in this context means "revealing". It's very revealing that you seem to think that the most important semantics of functional programs is the denotat

by tome 9y ago

"Telling" in this context means "revealing". It's very revealing that you seem to think that the most important semantics of functional programs is the denotational one when in fact lots of other important and useful semantics exist.

pron 9y ago
I know what "telling" means. I just didn't understand what was telling, since you asked for the denotational semantics so I described them [1]. Why would I think that some semantics are more important than others? [1]: Perhaps there's been a misunderstanding. Functional semantics means that expressions denote things similar to functions. Usually, operational semantics are state-machine semantics, certainly not functional semantics. If you'd asked for the state machine semantics, I would have described those.
- tome 9y ago
  I asked for the "functional semantics" which is a term you seem to have made up. I haven't heard anyone in the Haskell community or the programming languages community use this terminology. The reason I asked for it is that you seem to believe that it's the only semantics that functional programmers care about. You're wrong about that and this is what makes me think you really don't understand Haskell well enough to be critiquing it. I'm all in favour of you promoting technologies and approches that you think are beneficial. What I would ask you to stop doing (again) is critiquing Haskell without really understanding it.
  - pron 9y ago
    > "Functional semantics" seems to be a term you made up. Heh, well, in a way I guess you could say I made that "term" up, but it's not an atomic term. The formal semantics of a syntactic term is some object (in the semantic domain of the formalism) mapped to that term. If that object is a function (or something close to it), what you have is functional semantics. Similarly, you have relational semantics, behavior semantics, and any other kind that you may find useful; even evidence semantics, which assigns evidence objects to terms. I've heard some academics refer to it as "value semantics", which, I guess, hints to the fact that the denotation of a lambda application is the value that the lambda term reduces to, but I find that terminology to be unclear. I've heard Haskell programmers (in the pseudo-mathematical atmosphere that seems to be common in that community) refer to it as "referential transparency", which is downright misleading because referential transparency does actually have sort-of a well-defined meaning, and it's not quite that. I've heard Conal Elliot refer to it simply as "denotational" (as in "functional programming is denotational programming"), which is also misleading because not all denotations are functions. So, I find "functional semantics" to be both precise and clear. > You also seem to believe that it's the only semantics that functional programmers care about and this is why I say you have a big misunderstanding about Haskell. Where did you get that? What I may have said or alluded to, in so many words, is that denotational semantics are important for writing and analyzing programs, and I find that functional semantics don't make a great fit for non-sequential programs. After all, it only pays to think "denotationally" if the denotation is simple and a natural fit for the domain.
    - tome 9y ago
      I realised we went through all this nearly two years ago and failed to get anywhere! https://news.ycombinator.com/item?id=11907547 https://news.ycombinator.com/item?id=11907547 I'm afraid I still can't understand your position.
      - pron 9y ago
        I don't think it's complicated, but it is very much anti-dogmatic. I've written it above, but I'll repeat it. My position is that design is a matter of aesthetics (completely subjective) and pragmatics (also subjective, but can be measured empirically) -- not theory -- and aesthetics and pragmatics are the sources of value -- again, not theory.

by tome 9y ago

pron 9y ago

I know what "telling" means. I just didn't understand what was telling, since you asked for the denotational semantics so I described them [1]. Why would I think that some semantics are more important than others? [1]: Perhaps there's been a misunderstanding. Functional semantics means that expressions denote things similar to functions. Usually, operational semantics are state-machine semantics, certainly not functional semantics. If you'd asked for the state machine semantics, I would have described those.

tome 9y ago
I asked for the "functional semantics" which is a term you seem to have made up. I haven't heard anyone in the Haskell community or the programming languages community use this terminology. The reason I asked for it is that you seem to believe that it's the only semantics that functional programmers care about. You're wrong about that and this is what makes me think you really don't understand Haskell well enough to be critiquing it. I'm all in favour of you promoting technologies and approches that you think are beneficial. What I would ask you to stop doing (again) is critiquing Haskell without really understanding it.
- pron 9y ago
  > "Functional semantics" seems to be a term you made up. Heh, well, in a way I guess you could say I made that "term" up, but it's not an atomic term. The formal semantics of a syntactic term is some object (in the semantic domain of the formalism) mapped to that term. If that object is a function (or something close to it), what you have is functional semantics. Similarly, you have relational semantics, behavior semantics, and any other kind that you may find useful; even evidence semantics, which assigns evidence objects to terms. I've heard some academics refer to it as "value semantics", which, I guess, hints to the fact that the denotation of a lambda application is the value that the lambda term reduces to, but I find that terminology to be unclear. I've heard Haskell programmers (in the pseudo-mathematical atmosphere that seems to be common in that community) refer to it as "referential transparency", which is downright misleading because referential transparency does actually have sort-of a well-defined meaning, and it's not quite that. I've heard Conal Elliot refer to it simply as "denotational" (as in "functional programming is denotational programming"), which is also misleading because not all denotations are functions. So, I find "functional semantics" to be both precise and clear. > You also seem to believe that it's the only semantics that functional programmers care about and this is why I say you have a big misunderstanding about Haskell. Where did you get that? What I may have said or alluded to, in so many words, is that denotational semantics are important for writing and analyzing programs, and I find that functional semantics don't make a great fit for non-sequential programs. After all, it only pays to think "denotationally" if the denotation is simple and a natural fit for the domain.
  - tome 9y ago
    I realised we went through all this nearly two years ago and failed to get anywhere! https://news.ycombinator.com/item?id=11907547 https://news.ycombinator.com/item?id=11907547 I'm afraid I still can't understand your position.
    - pron 9y ago
      I don't think it's complicated, but it is very much anti-dogmatic. I've written it above, but I'll repeat it. My position is that design is a matter of aesthetics (completely subjective) and pragmatics (also subjective, but can be measured empirically) -- not theory -- and aesthetics and pragmatics are the sources of value -- again, not theory.