From: Chris Pine <cpine@...>
Date: 2004-07-15T13:56:06+09:00
Subject: Re: Functional Ruby (Re: Why I don't use Ruby.)

All right, I swore I wasn't going to, but no one else seems to be saying it, so...

On Wed, 14 Jul 2004 06:42:48 +0900, Sean O'Dell wrote:
> But within a function, local variables don't affect the return
> value.  True, every new function a developer writes could be simply
> nested calls to other functions, but for readability, local
> variables are very helpful, and as long as they're not global or
> stateful, they don't affect the return value, so to the outside
> world it's still just a function.

"...as long as they're not global or stateful..."

But variables are stateful!  Plus, in a language where functions can create functions (closures) "global" can be a relative term.

For example, in a purely functional (and fictional) language, this code would be illegal:

foo = {
  a = 4
  gimmeAnA = { a }  #  this function just returns `a'
  a = 5
  gimmeAnA
}

foo.call.call  #  returns 5, right??

`a' is local to `foo', but is global to `gimmeAnA'.  Since the local variable was rebound to 5, which changes what `gimmeAnA', this is not purely functional.

Now, you could fix easily fix this by saying that assignment introduces implicit scope, so there are 2 different variables `a' in 2 different scopes (the second hiding the first), and `gimmeAnA' returns 4, that is, the first `a' in the outer scope.  That would be purely functional, but only because you ARE NOT rebinding; you're creating a new binding.

You could do fancier things to allow something which "looks like" looping, but again, in a purely functional way where there really is no rebinding.  Syntactically, it can look like just about anything, but sematically there can be no rebinding (excusing context-specific compiler optimizations under the hood, like tail-call optimization).

Chris