On Wed, Sep 2, 2009 at 12:10 PM, Jonathan Cast <jonathancc...@fastmail.fm>wrote:
> On Wed, 2009-09-02 at 11:27 -0700, David Leimbach wrote: > > On Wed, Sep 2, 2009 at 11:08 AM, Richard Miller <9f...@hamnavoe.com> > > wrote: > > >> > > > http://graphics.cs.williams.edu/archive/SweeneyHPG2009/TimHPG2009.pdf > > >> > > > on p. 43/44 i believe it is claimed that one > > > cannot do CSP without pure functional > > > programming. > > > (p ⇒ q) ⇏ (¬p ⇒ ¬q) > > > > That's interesting because pure functional programming doesn't exist > > at all in the strictest sense on a computer. One MUST be able to > > cause side effects during computation or your CPU will just get hot... > > if even that. > > *delurk* > > That's an excessively strict view. You need *output* for a program to > be useful, but producing that output doesn't need to be intermixed with > the program's algorithm to be useful; you can compute first, then output > the results. > Compute what first? You compute input, to produce output. You have no choice really. In haskell the entry point is main :: IO (). I rest my case. Note that I didn't say "some code can't be pure", that's for the most part false (some would argue that even floating point math must be done in an impure way because one can set up the representation of floats differently, and that changes the purity of what would have been a pure function). Some code certainly can be executed in a pure sense, but at some point those values came in via a very dirty input process. The best part about Haskell is you can know by a functions type that no impure actions took place in a subset of your code. This does not falsify my claim that even pure functional programming languages require impure code. And if you prefer a plea to authority over logic, I haven't said anything that Simon Peyton Jones hasn't himself said about Haskell. Dave
