5 ms·

> https://gitlab.haskell.org/ghc/ghc/-/wikis/applicative-do https://gitlab.haskell.org/ghc/ghc/-/wikis/applicative-do can't help but chuckle at the accomplishm

> https://gitlab.haskell.org/ghc/ghc/-/wikis/applicative-do https://gitlab.haskell.org/ghc/ghc/-/wikis/applicative-do can't help but chuckle at the accomplishment of 40 years of research in functional PL, ending up with almost C-like syntax once again.

saagarjha 7y ago
Languages always face a gentle tug towards what’s popular and familiar.
- ashtonkem 7y ago
  Gentle seems to understate it, in my opinion.
random314 7y ago
So much chuckling. I too can't help but chuckle at some of the substance less commentary at HN, where chuckling is a substitute for inability to contribute anything to a discussion.
- tasuki 7y ago
  Your comment is a little harsh.
  - asdkjh345fd 7y ago
    I don't think it is harsh enough. The comment is devoid of substance and wrong.
    - jcelerier 7y ago
      care to detail how do x <- a y <- b return (f x y) isn't basically imperative syntax ? hint: if you can get from it to C (or pascal or python or whatever) simply by adding a couple types, semicolons and replacing operators, it's C.
      - lmm 7y ago
        How is that any more or less imperative than the standard Haskell syntax: let x = a y = b in (f x y) ? Which in turn is very much like OCaml syntax or plenty of other functional syntaxes.
      - jhomedall 7y ago
        IIRC that desugars to a >>= (\x -> b >>= (\y >>= return (f x y))) . I don't write Haskell, so that might be slightly off This could be doing any one of: - flatmapping over lists - doing a computation with Maybe types, producing Nothing if a or b are nothing - doing IO - managing futures - pretty much anything, actually Don't confuse 'x <- a' with assignment, or 'return' with returning a value. Another way of looking at it, (f x y) might be invoked: - once - never - more than once - later
      - asdkjh345fd 7y ago
        There is no such thing as imperative syntax. Syntax is completely orthogonal to being imperative, which is semantic not syntactic. It isn't "almost C-like syntax", unless you define that to mean "if I do any amount of search and replace I can make it into valid C code that has completely different semantics". "x <- a" in haskell is not at all the same as "x = a" in C. And that isn't the reason I said your comment is wrong. Your comment is wrong because do notation is not the result of "40 years of research in functional PL", nor is it an accomplishment. It is simple syntactic sugar that didn't come from research at all. Your comment could be accurately summarized as "I would like to express how smug I feel for not learning something".
        jcelerier 7y ago
        > Your comment is wrong because do notation is not the result of "40 years of research in functional PL" are you kidding me ? if a 2016 paper from Simon Peyton Jones isn't research then what is ? (https://dl.acm.org/doi/pdf/10.1145/3241625.2976007 https://dl.acm.org/doi/pdf/10.1145/3241625.2976007)
        asdkjh345fd 7y ago
  - random314 7y ago
    Don't think you have noticed. But there is a chuckling epidemic on HN. It acts as a tool to appear smug and superior while not providing any sensible argument or logic. The last time there was someone chuckling, I was way more civil. https://news.ycombinator.com/item?id=22712767 https://news.ycombinator.com/item?id=22712767
- ljm 7y ago
  I suppose you must be chuckling at yourself then. And me, now. And everyone else who replies. This thread is silly.
lmm 7y ago
It took decades years of research in mathematics to come up with a way to rigorously do the kind of calculus that Riemann and Cauchy could do intuitively. But when students tried to do analysis the way Riemann and Cauchy did, they just proved (or rather "proved") all kinds of absurdities. Going back, it's the same story with calculus itself: Newton and Leibnitz could do it intuitively, but it took hundreds of years to come up with a rigorous foundation that allowed mere mortals to do the same kind of thing safely.
rednum 7y ago
I think there's other way of looking into this: in Haskell we have well defined semantics (when you look at function you have explicit information about what is happening) and we managed to get to familiar syntax. In C we have very messy semantics: "everything can happen everywhere". Java stays somewhere in between (though closer to C side): when you have a method in some class it most likely touches only visible methods/fields of its arguments and fields of this class (obviously there are some escape hatches like unsafePerformIO, but most of your codebase will not use this). I believe being able to understand code on high level quickly is a good thing in engineering. Wouldn't it be nice if looking at some part of code you could say that it actually is calling microservices X, Y and Z and no other microsevices? In Haskell you could have that. I don't see any fundamental reason why such functionality couldn't be brought into an imperative language at some point (but maybe I'm ignorant about PL theory). (FWIW I don't believe in Haskell going mainstream at any point).
- jcelerier 7y ago
  > Wouldn't it be nice if looking at some part of code you could say that it actually is calling microservices X, Y and Z and no other microsevices? What always makes me a bit uneasy about that is the absence of proper escape hatch in functional langs. I am not old and yet I have already been in time-critical situations - where all you have is sometimes only a few minutes - to do a quick hack that will save a few more hours to actually investigate and do the proper fix (think physical installations). And, I would really not call unsafePerfomIO a proper escape hatch given the big attached warning that comes with it: > If the I/O computation wrapped in unsafePerformIO performs side effects, then the relative order in which those side effects take place (relative to the main I/O trunk, or other calls to unsafePerformIO) is indeterminate.
  - lmm 7y ago
    > And, I would really not call unsafePerfomIO a proper escape hatch given the big attached warning that comes with it: > If the I/O computation wrapped in unsafePerformIO performs side effects, then the relative order in which those side effects take place (relative to the main I/O trunk, or other calls to unsafePerformIO) is indeterminate. Isn't that exactly the situation you'd be in in a non-functional language by default? E.g. in C, evaluation order for function arguments is indeterminate, so the order of any side effects that each argument does is also indeterminate. The only way to force a particular evaluation order is to arrange your code to have suitable sequence points in place - which is not really any easier than composing IOs properly in Haskell.
bhaak 7y ago
Most criticism of C isn't about its syntax. :-)
gnulinux 7y ago
That's a good thing. C's syntax is fine; C's guarantees and semantics is the problem. Here we have a similar syntax, but infinitely better guarantees and well-defined sematics.
yomly 7y ago
I mean it's fun because you get a pithy statement out of it - but at the heart of this is the human notion of computation of which the two leading models of expression are the lambda calculus and the Turing machine. They're both equivalent so it should almost be expected that if you go far enough along the horseshoe you end back on the other side. A bit like how Java eventually got lambdas. But when the capitalists come up with communism, it is interesting to observe the implementation they come up with after travelling the road they have come, much like when the communists come up with capitalism...
whateveracct 7y ago
that's..not the right takeaway from -XApplicativeDo, or do notation in general even. I'm actually not sure what the C-like syntax you're referring to is? The fact that it reads like imperative code (even though it could be defining a parser or something not imperative)? Or the fact that it uses the word `return` (many use `pure` instead..`return` is free for anyone to bind a variable too)?
dllthomas 7y ago
ApplicativeDo allows the previously well established monadic do syntax to be applied in cases where the type you're working with is only applicative. It's not new syntax - it's been around since 1996.

saagarjha 7y ago

Languages always face a gentle tug towards what’s popular and familiar.

ashtonkem 7y ago
Gentle seems to understate it, in my opinion.

random314 7y ago

So much chuckling. I too can't help but chuckle at some of the substance less commentary at HN, where chuckling is a substitute for inability to contribute anything to a discussion.

tasuki 7y ago
Your comment is a little harsh.
- asdkjh345fd 7y ago
  I don't think it is harsh enough. The comment is devoid of substance and wrong.
  - jcelerier 7y ago
    care to detail how do x <- a y <- b return (f x y) isn't basically imperative syntax ? hint: if you can get from it to C (or pascal or python or whatever) simply by adding a couple types, semicolons and replacing operators, it's C.
    - lmm 7y ago
      How is that any more or less imperative than the standard Haskell syntax: let x = a y = b in (f x y) ? Which in turn is very much like OCaml syntax or plenty of other functional syntaxes.
    - jhomedall 7y ago
      IIRC that desugars to a >>= (\x -> b >>= (\y >>= return (f x y))) . I don't write Haskell, so that might be slightly off This could be doing any one of: - flatmapping over lists - doing a computation with Maybe types, producing Nothing if a or b are nothing - doing IO - managing futures - pretty much anything, actually Don't confuse 'x <- a' with assignment, or 'return' with returning a value. Another way of looking at it, (f x y) might be invoked: - once - never - more than once - later
    - asdkjh345fd 7y ago
      There is no such thing as imperative syntax. Syntax is completely orthogonal to being imperative, which is semantic not syntactic. It isn't "almost C-like syntax", unless you define that to mean "if I do any amount of search and replace I can make it into valid C code that has completely different semantics". "x <- a" in haskell is not at all the same as "x = a" in C. And that isn't the reason I said your comment is wrong. Your comment is wrong because do notation is not the result of "40 years of research in functional PL", nor is it an accomplishment. It is simple syntactic sugar that didn't come from research at all. Your comment could be accurately summarized as "I would like to express how smug I feel for not learning something".
      - jcelerier 7y ago
        > Your comment is wrong because do notation is not the result of "40 years of research in functional PL" are you kidding me ? if a 2016 paper from Simon Peyton Jones isn't research then what is ? (https://dl.acm.org/doi/pdf/10.1145/3241625.2976007 https://dl.acm.org/doi/pdf/10.1145/3241625.2976007)
        asdkjh345fd 7y ago
- random314 7y ago
  Don't think you have noticed. But there is a chuckling epidemic on HN. It acts as a tool to appear smug and superior while not providing any sensible argument or logic. The last time there was someone chuckling, I was way more civil. https://news.ycombinator.com/item?id=22712767 https://news.ycombinator.com/item?id=22712767
ljm 7y ago
I suppose you must be chuckling at yourself then. And me, now. And everyone else who replies. This thread is silly.

lmm 7y ago

It took decades years of research in mathematics to come up with a way to rigorously do the kind of calculus that Riemann and Cauchy could do intuitively. But when students tried to do analysis the way Riemann and Cauchy did, they just proved (or rather "proved") all kinds of absurdities. Going back, it's the same story with calculus itself: Newton and Leibnitz could do it intuitively, but it took hundreds of years to come up with a rigorous foundation that allowed mere mortals to do the same kind of thing safely.

rednum 7y ago

I think there's other way of looking into this: in Haskell we have well defined semantics (when you look at function you have explicit information about what is happening) and we managed to get to familiar syntax. In C we have very messy semantics: "everything can happen everywhere". Java stays somewhere in between (though closer to C side): when you have a method in some class it most likely touches only visible methods/fields of its arguments and fields of this class (obviously there are some escape hatches like unsafePerformIO, but most of your codebase will not use this). I believe being able to understand code on high level quickly is a good thing in engineering. Wouldn't it be nice if looking at some part of code you could say that it actually is calling microservices X, Y and Z and no other microsevices? In Haskell you could have that. I don't see any fundamental reason why such functionality couldn't be brought into an imperative language at some point (but maybe I'm ignorant about PL theory). (FWIW I don't believe in Haskell going mainstream at any point).

jcelerier 7y ago
> Wouldn't it be nice if looking at some part of code you could say that it actually is calling microservices X, Y and Z and no other microsevices? What always makes me a bit uneasy about that is the absence of proper escape hatch in functional langs. I am not old and yet I have already been in time-critical situations - where all you have is sometimes only a few minutes - to do a quick hack that will save a few more hours to actually investigate and do the proper fix (think physical installations). And, I would really not call unsafePerfomIO a proper escape hatch given the big attached warning that comes with it: > If the I/O computation wrapped in unsafePerformIO performs side effects, then the relative order in which those side effects take place (relative to the main I/O trunk, or other calls to unsafePerformIO) is indeterminate.
- lmm 7y ago
  > And, I would really not call unsafePerfomIO a proper escape hatch given the big attached warning that comes with it: > If the I/O computation wrapped in unsafePerformIO performs side effects, then the relative order in which those side effects take place (relative to the main I/O trunk, or other calls to unsafePerformIO) is indeterminate. Isn't that exactly the situation you'd be in in a non-functional language by default? E.g. in C, evaluation order for function arguments is indeterminate, so the order of any side effects that each argument does is also indeterminate. The only way to force a particular evaluation order is to arrange your code to have suitable sequence points in place - which is not really any easier than composing IOs properly in Haskell.

bhaak 7y ago

Most criticism of C isn't about its syntax. :-)

gnulinux 7y ago

That's a good thing. C's syntax is fine; C's guarantees and semantics is the problem. Here we have a similar syntax, but infinitely better guarantees and well-defined sematics.

yomly 7y ago

I mean it's fun because you get a pithy statement out of it - but at the heart of this is the human notion of computation of which the two leading models of expression are the lambda calculus and the Turing machine. They're both equivalent so it should almost be expected that if you go far enough along the horseshoe you end back on the other side. A bit like how Java eventually got lambdas. But when the capitalists come up with communism, it is interesting to observe the implementation they come up with after travelling the road they have come, much like when the communists come up with capitalism...

whateveracct 7y ago

that's..not the right takeaway from -XApplicativeDo, or do notation in general even. I'm actually not sure what the C-like syntax you're referring to is? The fact that it reads like imperative code (even though it could be defining a parser or something not imperative)? Or the fact that it uses the word `return` (many use `pure` instead..`return` is free for anyone to bind a variable too)?

dllthomas 7y ago

ApplicativeDo allows the previously well established monadic do syntax to be applied in cases where the type you're working with is only applicative. It's not new syntax - it's been around since 1996.