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.
Furthermore, I don't think it's sophistry to say that you don't need
side effects to do output. ALGOL-derived languages use side effects for
output, because (to take C as an example) the type of an expression like
print("Hello, world\n")
is taken to be `int', and thus the `value' of that expression must be
some integer --- say, 13. Then you need to add a concept of `side
effects' to express the fact that there's more going on here than just
calculating the number 13.
Purely functional programming doesn't eschew I/O (although it encourages
a style that separates I/O from algorithms --- as does good programming
style in any language); rather, it re-works the types of the I/O
operations so that, if you have a function
foo :: String -> Int
the value of
foo "Hello, world!\n"
really is just an integer (and there's nothing else going on to
introduce side-effects to talk about). Whereas if you have a function
bar :: String -> IO Int
then the value (as expressed in the language and understood by the
programmer) of
bar "Hello, world!\n"
is a combination of I/O behavior, concurrency, etc. So you don't need
to introduce a concept of `side effects' to talk about those things.
If you were building a denotational semantics for C, this how you would
deal with I/O. The value (denotation) of a C expression of type int
would be a combination of I/O behavior, assignment behavior, etc., as
well as (possibly, due to the possibility of non-termination) an
integer. Purely functional programming just reduces the degree of
difference between the denotational semantics of the language and the
programmer's mental model of it.
Which is very likely all I have to say on the subject.
jcc
