4 ms·

GHC isn't even close to "pure lambda calculus", sorry. For one thing, there's a lot of fuzziness around e.g. "seq", strict pattern matching vs. lazy pattern mat

GHC isn't even close to "pure lambda calculus", sorry. For one thing, there's a lot of fuzziness around e.g. "seq", strict pattern matching vs. lazy pattern matching, etc. which leads far afield from LC. For another, there's "IO" which doesn't have any kind of formal semantics in Haskell, nevermind LC, so... EDIT: I'm not saying it's not useful as a model, I'm just questioning whether it's practical. I think both LC and the Actor model are both interesting and valuable, I just don't think they should be the foundational model for ABSOLUTELY EVERYTHING as e.g. Alan Kay seems to be advocating. EDIT#2: I should say... I realize that LC actually is Turing-Complete, as I believe Hewitt has also demonstrated that the Actor model is. However, I believe Hewitt assumes infinite queues. As always, infinity gives quite a bit of leeway.

dualogy 10y ago
> GHC isn't even close to "pure lambda calculus" Well I reckon you're using a "strict" definition of pure and I'm using a "lazy" one.. ;) Let's say Haskell-the-language is on the purer side of things and GHC-the-compiler by necessity closer to the messy not-so-pure real-world-er side of programs that run acceptably speedily reliably and sturdily most-of-the-time.. (IO monad "while used by the coder" seems plenty pure to me other than the background knowledge that eventually with a `main` entry point it will become hooked up with actual I/O.. but that's "semantics" hehe)
- lomnakkus 10y ago
  Alright, then -- I think we agree for all practical purposes :). Still, I think it is important to realize that while "IO" is 'sort-of-a-monad'... the truth isn't quite that simple :). There's a lot of nastiness hidden behind it, especially FFI and exception-related things... ugh. EDIT: My original point was mostly that maybe he hadn't thought this whole "async every method call!" thing through. That... leads to a mess, especially if every single "thing" you do is a "method call".
sriku 10y ago
It looks like what you're trying to say is that the difference between theory and practice is that in theory there isn't any but in practice there is. (Someone else said this, not me)

dualogy 10y ago

> GHC isn't even close to "pure lambda calculus" Well I reckon you're using a "strict" definition of pure and I'm using a "lazy" one.. ;) Let's say Haskell-the-language is on the purer side of things and GHC-the-compiler by necessity closer to the messy not-so-pure real-world-er side of programs that run acceptably speedily reliably and sturdily most-of-the-time.. (IO monad "while used by the coder" seems plenty pure to me other than the background knowledge that eventually with a `main` entry point it will become hooked up with actual I/O.. but that's "semantics" hehe)

lomnakkus 10y ago
Alright, then -- I think we agree for all practical purposes :). Still, I think it is important to realize that while "IO" is 'sort-of-a-monad'... the truth isn't quite that simple :). There's a lot of nastiness hidden behind it, especially FFI and exception-related things... ugh. EDIT: My original point was mostly that maybe he hadn't thought this whole "async every method call!" thing through. That... leads to a mess, especially if every single "thing" you do is a "method call".

sriku 10y ago

It looks like what you're trying to say is that the difference between theory and practice is that in theory there isn't any but in practice there is. (Someone else said this, not me)