From: Eleanor McHugh <eleanor@...>
Date: 2007-05-31T10:51:21+09:00
Subject: Re: Introducing the "it" keyword

On 29 May 2007, at 14:17, Gregory Seidman wrote:
> Looking at it from a different perspective, consider whether any  
> proposed
> change to Ruby moves it closer to language X (which I'm equating to  
> Perl)
> or closer to language Y (which I'm equating to Lisp). Moving toward  
> X means
> making things easy to express tersely at the expense of overall  
> readability
> and maintainability. Moving toward Y means simplifying the  
> expression of
> things using existing syntax and functionality. I claim that we should
> strive to avoid shortcuts that bring Ruby closer to X and strive to  
> solve
> our problems in ways that bring Ruby closer to Y.

I should just point out that Ruby is not Lisp, and that whilst Lisp  
has many admirable traits, there are many Ruby programmers who like  
it that way.

On to the topic in question: the idea of the OP that we should be  
able to write

> 	return it if |v + 1| < 10

addresses a very real issue as the fragments

	t = f(n)
	return t if t != x

and

	t = f(n)
	return t unless t == x

pop up regularly in my code. As the whole bundle is a single  
operation it _should_ be possible to write it in atomic form along  
the lines of

	return %$ if f(n) != x
	return %$ unless f(n) == x
	puts %$[0], %$[1], %$[2] if f(n) > 0

where %$ is a placeholder for substitution of the value returned by f 
(n).

I've used %$ in these examples due to the conceptual similarity to  
substitution in the sprintf method and the use of subscripts adds the  
possibility of consuming multiple return values, although I'm not  
suggesting it's a _good_ notation :) Whatever the specific token, I  
think punctuation would be a better choice than a keyword because it  
focuses the eye on the fact that something special is happening and  
makes explicit that neither a local variable nor a function call is  
being evaluated where the substituted value is being used. Under the  
hood the interpreter could avoid messing with local variables, the  
result would be generated just once, it could be garbage collected  
immediately on completion and probably all kinds of cleverness could  
be applied.

Of course this approach fails to solve other common cases such as

	return f(n), f(m) if f(n,m) == x


Ellie

Eleanor McHugh
Games With Brains
----
raise ArgumentError unless @reality.responds_to? :reason