Re: [9fans] nice quote

[Jonathan Cast <jonathanccast@fastmail.fm>]

On Wed, 2009-09-02 at 11:27 -0700, David Leimbach wrote:
> On Wed, Sep 2, 2009 at 11:08 AM, Richard Miller <9fans@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