Warp wrote:
>   Thus a purely functional language is mostly impractical. Quoting
> wikipedia:
> 
> "Purely functional programs have no side effects. This makes it easier
> to reason about their behavior. However, almost no programmers bother
> to write purely functional programs, since, by definition, a program
> with no side effects (one that accepts no input, produces no output,
> and interfaces with no external devices ) is formally equivalent to a
> program that does nothing;

Quoting wikipedia is not always that useful:  that section is most 
likely vandalism by some angry COBOL programmer.

Surely separation of concerns is good as is reducing side-effects to a 
minimum.  To say a purely functional program is incapable of accepting 
input or generating output is not correct:  if anything, a purely 
functional program is able to, in shared memory, take a list as input 
and generate a list as output.  An outside program can write the input 
list in memory, call the pure program on it and read its output and 
write to file.  That's, AFAIK, is what was done in the old days of 
Haskell:  delayed list IO.

More practically, functional language compilers and runtimes carry out 
the ugly side-effect bits while the purely functional programs do their 
stuff and get written as if acting on purely side-effect free 
datastructures.  That's monadic IO today.

Post a reply to this message