On 29.05.2007 15:17, Gregory Seidman wrote:
> On Tue, May 29, 2007 at 04:55:01PM +0900, Ronald Fischer wrote:
> Implicit variables make me queasy. I don't like Perl's $_, I don't like x86
> assembly's numerous ops with implicit source and/or destination registers,
> and I don't like a magical "it" appearing out of nowhere.

I couldn't agree more.

>> I think if we only want to introduce an auxiliary variable as
>> "abbreviation" for an expression which occurs repeatedly in a block, Ruby
>> indeed has many ways to do it, as do most other languages I know. The
>> problem becomes interesting IMO if we are libarated from the requirement
>> to invent a name for such a variable.
>>
>> The OP suggested to have a "reserved variable" named 'it' which is kind
>> of implicitly bound, but this is a special case for a special type of
>> programming pattern. My alternative suggestion go into a more general
>> direction, where you can have more than one binding, and where it is the
>> programmer's choice whether or not to name the variables.
> 
> The OP brought up an interesting issue, but what made it interesting is not
> the implicit binding but the need for a scoped temporary value. There are
> three important optimization goals to it:
> 
> 1) avoid holding onto memory any longer than necessary (memory)
> 2) avoid clumsy use of temporary values (readability)
> 3) avoid recomputing the same value more than once (speed)

3 is also about semantics which might even be more important than speed. 
  There can be a huge semantic difference between evaluating an 
expression once or twice.

Other than that I totally agree with your analysis.  This sums it up 
very nicely!

> See http://weblog.raganwald.com/2006/10/why-are-local-variables-bad.html
> for a discussion of local variables and better ways of doing things
> (including the functional let).
> 
> Importantly, an implicit variable name has two problems. First, it reduces
> readability. Second, even if naming the variable explicitly is optional
> rather than required, you get the same sorts of maintenance problems caused
> by the optionally braceless block notation for single statements in C-derived
> syntaxes, e.g.
> 
> let Time.now in
>   puts "starting at #{$1}"
>   let a+b+c in
>     puts "sum = #{$1}" if $1 > 3
>   end
> end
> 
> ..is as bad an issue as...
> 
> for (int i=0; i<5; ++i)
>   printf("%d\n", i);
>   fprintf(stderr, "%d\n", i);
> 
> Basically, if you need to add an outer scope, you have to renumber all of
> the temporaries. This is unnecessary and unreasonable pain to inflict on
> maintainers of the code, even if it's your own code.
> 
> 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 kind of agree although I am not sure whether I'd take Lisp as 
prototype.  I believe it is a narrow path to make a language readable 
and maintainable.  The fact that Lisp's macros blend in with the 
language syntax is very nice on one hand because it allows to define 
"new syntax" easily and make certain constructs look familiar.  On the 
other hand the missing syntactic distinction between macro and function 
invocation makes it hard to understand what's going on at times.  Maybe 
it's just me lacking Lisp practice but I think it's a double edged sword.

Thank you for your analysis!

Kind regards

	robert