From: "Hal E. Fulton" <hal9000@...>
Date: 2002-09-08T14:03:05+09:00
Subject: Re: Larry Wall's comments on Ruby

----- Original Message ----- 
From: "Austin Ziegler" <austin@halostatue.ca>
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>
Sent: Saturday, September 07, 2002 11:46 PM
Subject: Re: Larry Wall's comments on Ruby


> I personally think that Ruby's approach (which is
> mildly reminiscent of Pascal and Ada on this matter) is cleaner than
> either Python's (which is reminiscent of Fortran and COBOL) or
> Perl's (which is also that of C/C++/Java/etc.) in that the block is
> cleanly delineated by meaningful tokens instead of symbols or
> spaces.
> 
> def fun(foo)
>     ...
> end
> 
> to me seems to be much cleaner than
> 
> fun(foo):
>   ...
> 
> or
> 
> sub fun(foo)
> {
>     ...
> }
> 
> even though they ultimately mean the same thing. From a computer's
> perspective, it's far easier to track scope with single-character
> symbols (and it helps with editor paren-matching, too); IMO, from a
> human's perspective it's far easier to track scope with meaningful
> tokens than merely by space (especially since a single space error
> can cause compile problems). Of course, judicious use of formatting
> can make all of the things easier to read for the human.

Yes, I agree...

I even rather like the way some languages "modify"
the end token: end def, end while, end if, etc.

This certainly prevents the inane comments to the same
effect that people put in, and even gives an additional
hint to the interpreter. (It would prevent the mistake
that I often make where I leave out an 'end' and the
parser isn't able to catch it until 50 lines later.)

My understanding is that Ruby *used* to have these 
(before I ever saw it), but they conflicted with the
"modifier" forms of if, until, unless, while, etc.
Can't really have both, unless you want some heavy-duty
parser impact.

One idea I've wondered about is making the parser "smart" 
enough to (at least) speculate about where an error *really*
happened, based on indentation.

This would be a small tip of the hat to Python, I suppose.
If an 'end' was indented differently from its corresponding
beginning, a warning would be generated. But then it would
interfere with people's styles, and there would always be
some people who would mix spaces and tabs in creative and
irritating ways and set the tabstops to some setting that
the interpreter could never hope to guess.

It would work for *me*, though. :) Maybe I should create a
Ruby version of lint (rint?).

Hal