Why I don't use Ruby.

[gabriele renzi]

il Thu, 15 Jul 2004 07:42:31 +0900, Nicholas Van Weerdenburg

oh, I see. I don't know how to do this, anyway, but seem possible to
hack to me, even if greatly not efficient

 

[Chris Pine]

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

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

 

[Rainer Joswig]

Tail-call elimination -- the recursive function will be optimized into
a loop by the compiler.

Lennon

Hmm

a) it can't be optimized because the function call is not a tail call
(unless the compiler does some other high-level transformations).
b) still some value needs to be changed. the thing just does not compute
a product in any useful way.

Say, if you want to compute a product from 1 to n, you need to
count somewhere. The function in the paper does not.

Here is the recursive version in Lisp:

(defun prod (m n f)
(if (= m n)
m
(* (funcall f m)
(prod (+ 1 m) n f))))

And here is a tail-recursive version:

(defun prod (m n f &optional (acc n))
(if (= m n)
acc
(prod (+ 1 m) n f
(* (funcall f m) acc))))

; product of numbers from 1 to 4
(prod 1 4 #'identity) -> 24

 

[chain_lube]

Lots of functional languages lack pattern matching. Scheme, for
example. One can write Scheme-styled code in Ruby.

Not quite true. Scheme itself lacks any "pattern matching" facility,
though.

However, there is one sound Scheme distribution which includes
pattern-matching: it is called "Bigloo".

Bigloo was also used for the new PhP compiler (see slashdot).

By the way: Bigloo has also types!

I use Bigloo for numerical computations in physics.

Fensterbrett

 

[chain_lube]

In Scheme, sum would be:

(define (sum xs)
(if (null? xs)
0
(+ (car xs) (sum (cdr xs)))))

Or in Bigloo with pattern-matching:

(define (sum xs)
(match-case xs
(() 0)
((?h ???t)
(+ h (sum t)))))


or with types:

(define (sum:bj xs:air)
(match-case xs
(() 0)
((?h ???t)
(+ h (sum t)))))


Bigloo its pattern-matching facility is as sophisticated as OCaml its one.

Fensterbrett