Erlang questions on comp.lang.functional.

Chris Pressey <>
Wed Mar 5 07:12:07 CET 2003


On Mon, 3 Mar 2003 02:59:05 +0100 (MET)
Marc Ernst Eddy van Woerkom <> wrote:

> > I think the reality is it is impossible to build a programming
> > language that doesn't have side effects. 
> 
> It starts with I/O, which is done as side effect in Prolog. :) 
> 
> I wonder how I/O is considered by strict functional programmers,
> a function like
> 
>  int f() = return len(readkbdstring)
> 
> isn't supposed to always return the same value, or?
> Worse, it is not even predictable.
>
> Now go from I/O to networked I/O. 

My (fuzzy) understanding is that referentially transparent I/O requires
lazy evaluation - thus confirming the wisdom (which we, deep in our
hearts, know *unshakably* to be true) that no language except Haskell can
*really* be called functional.  After all:

- there is NO way to analyze code that isn't referentially transparent!
  (Church showed how Turing's model is inherently flawed!)
- proving code is something you should always do AFTER it's written!
  (Never during!  What a waste of time THAT would be!)
- proving code is a ROCK SOLID GUARANTEE that the proof is correct, too!
  (There's a Knuth quote that'll back me up on this!)

My, but I'm snarky tonight.  Must have been that hot salsa on an empty
stomach.  Anyway.  My feeling is that referentially transparent I/O (or
referentially transparent *everything*, if you like) is
  a) very beautiful; and
  b) completely unnatural.
But it's no secret that I'm biased; Haskell seems to me like its sole
purpose is to make mathematicians salivate.  Again, I have to say, my
understanding is fuzzy, probably because anyone who tries to explain
Haskell to me immediately goes into "mathematician's-dream mode", but I
for one can't see why one would choose one language feature which makes
sharing explicit (single assignment) then go and choose another that hides
sharing (monads.)  Aren't we right back where we started?  And don't get
me started about Haskell's readablity or I'll start drawing unflattering
(but, AFAICT, completely accurate) parallels between it and Unlambda...

As to the original post which started this thread: old superstitions die
hard.  The poster was looking for a systems-construction language (strong
typing + native compilation + thorough optimization, presumably) that
also supports hot-swapping code.  All I can say to that is - good luck!

OK, enough vitriol - back to your regularly scheduled erlang-questions
list...

-Chris



More information about the erlang-questions mailing list