From: zuzu <sean.zuzu@...>
Date: 2004-07-10T06:31:09+09:00
Subject: Re: Functional Ruby (Re: Why I don't use Ruby.)

On Sat, 10 Jul 2004 05:37:53 +0900, Lennon Day-Reynolds
<rcoder@gmail.com> wrote:
> Ruby objects are mutable in the sense that you can do the following:
> 
> a = []
> a.add(1)
> 
> The internal state of 'a' has been changed, which is a no-no in
> functional languages. Of course, most of them do so anyway for tasks
> like I/O, and use some sort of abstraction (which often looks eerily
> like an 'object') to hide those side-effects from the programmer.
> 
> Lennon

hmm...  on the surface i understand and agree.

however, here's my line of thought:  you are referring to the internal
state of the _object_, treating it as "data".  this is a quite common
model, and i'm not throwing it out wholesale.  however, objects are
actually a unique beast; the whole is greater than the sum of its data
and functions.  for sake of argument, let us *not* think of objects as
data.  the function .add(1) simply transforms the return function of
the array...

my hypothesis here is that referential transparency (statelessness)
attempts to resolve the problem of the data in memory values from
changing.  for example, in C:

int value = 47;   /* a memory space of size integer is defined, and a
data value of "47" is stored inside that memory.  tell the compiler
that all references to "value" point to that memory address within
this scope. */
value = 52;  // null the data in the memory address at "value" and
write inside it the value of "52"

this seems like a bad thing because who knows why that memory address
sometimes will return "47" and othertimes will return "52" without
actually stepping through the program.  and even then, any programmer
will have to guess as to what the original programmer's intentions
were in doing so.  hence people like referential transparency because
it says "all values simply represent the process of other processes of
some original value."  (of course, that original value is where
referential transparency breaks down, such as with I/O, because again
only the users knows why the hell they enter the data they do when
they do.)  the nice thing about FP is that it's timeless; you don't
need nor care about when, just how.

from this point of view, does an object in a pure OO environment
constitute an arbitrary change in a memory value, or can the process
be reversed without using a clocktick as a reference?  if the process
can so be reversed, i would argue something immutable / referentially
transparent is going on, at least within "ruby space".

-z