From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jonathan Cast <jonathanccast@fastmail.fm>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
In-Reply-To: <3e1162e60909021127m7c22b518hf2255495dce5ee30@mail.gmail.com>
References: <5db2df69e768a7259b8a1e698abddd3f@coraid.com>
	<32125c2033c0f63e5bb24548c7bc934f@hamnavoe.com>
	<3e1162e60909021127m7c22b518hf2255495dce5ee30@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Date: Wed,  2 Sep 2009 12:10:51 -0700
Message-Id: <1251918651.30178.12.camel@jcchost>
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: Re: [9fans] nice quote
Topicbox-Message-UUID: 5fb4171a-ead5-11e9-9d60-3106f5b1d025

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/TimHPG20=
09.pdf
>         >>
>         > on p. 43/44 i believe it is claimed that one
>         > cannot do CSP without pure functional
>         > programming.

>         (p =E2=87=92 q) =E2=87=8F (=C2=ACp =E2=87=92 =C2=ACq)


> 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