[Haskell-beginners] Re: Applicability of FP unchanging things to real world changing things

[Heinrich Apfelmus]

Stephen Blackheath wrote:
> Glurk wrote:
>> I think a lot of people, looking at the real world, would answer, yes, it
>> clearly IS the same book, now in a different state. And yes, I CAN
>> step into the same river twice. This is how people see and think
>> about the real world.
> 
> [...]
> Here's one way to structure the library:
> 
> lend :: BookID -> Library -> Library
> 
> actOn :: Request -> Library -> (Library, [Result])
> actOn (Lend bookID) lib = (lend bookID lib, [])
> ....
> 
> -- | A library is a transformation from Request events (e.g. 'lend')
> -- to Result events (e.g. overdue book email),
> -- implemented using lazy lists.
> library :: Library -> [Request] -> [Result]
> library lib0 reqs = concat $ snd $ mapAccumL (\lib req -> actOn req lib)
> lib0 reqs
> 
> Now, are we mutating a library, or are we not?  In spite of what the
> more Zen-oriented Haskellers might say, it seems to me we are.  Call me
> uneducated but I can't really see what is actually wrong with the idea
> of mutation of state over time, where the abstraction is appropriate.
> Perhaps the point is that in Haskell, this is one of many ways of
> looking at it.

I think it's entirely fine to interpret the above code snippet as a
program that changes the current library. ("To change" can be read two
ways: either to *ex*change the current library for a new one or to
*mutate* the current library. I lean towards the former because it is
closer to what Haskell actually does; but such fine print matters little.)

However -- and this is the key point -- that doesn't mean that the model
has to change or mutate anything. Put differently, I would attribute a
lack of imagination to any notion that the model must be formulated in
terms of mutable variables.

In other words, whether the real world mutates things and whether we
interpret it that way is quite irrelevant; the real question is whether
the programming language we use to model the real world should include
mutation (in the form of mutable variables). And the answer to that not
only depends on how much the language caters to primordial intuition, as
Glurk argues, but also on how fluent and expressive the language is and
how it "interacts with itself".

The premise of Haskell is that we pay a small translation cost from pure
functions to an interpretation involving mutations, a cost that can be
reduced to zero with proper training, but reap a big profit when it
comes to manipulating and composing pure functions / programs.


Regards,
Heinrich Apfelmus

--
http://apfelmus.nfshost.com