[ruby-talk:04365] Re: Thirty-seven Reasons [Hal Fulton]Love[s ] Ruby

Hal:
> > > REASON 21
> > > 21.  Reserved words aren't. It's perfectly allowable to use an
> > > identifier that is a so-called "reserved word" as long as the parser
> > > doesn't perceive an amibiguity. This is a breath of fresh air.

David:
> > It is?  I don't think anyone should use reserved words as 
> > normal variables.  A compiler or interpreter writer should 
> > almost disallow reserved words as a matter of principle - 
> > though in extreme conditions, it might be useful to use them.

Conrad:

> The big gotcha is: "... as long as the parser doesn't perceive an
> ambiguity.". This gives the usability of this feature a somewhat
> counter-intuitive Perl-like dependency on context. If you had a (say
> "AI") program that dynamically generated Ruby code that 
> turned incoming
> text words (say with _a_ being substituted for apostrophes and so on)
> into variable names, your code would likely be sooner or later tripped
> up by this feature.

Well, I have to say I'm standing with Hal here. What isn't restricted does
not have to be done. No one keeps you from jumping over the edge on high and
steep mountain, but most of the time you wouldn't do it. Sometimes you
*want* to do it, and it's nice no one has built a net to catch you. If I'd
like BASE jumping very much, I'd consider finding that net builder and let
him test his nets personally...

But back to the real life, and about the code Hal has written himself at
http://www.hypermetrics.com/rubyset.html (snippet):

  class Object   # Why has to be outside module?
    def in(x)
      x.include? self
    end
  end

This code allows him to write

  def test_member_01
    x = Set(2,3,4)
    (2.in x) && (3.in x) && (4.in x)
  end

Yet 'in' is a reserved word as there's for-in construct and parse.y defines
explicitly kIN.

I agree that most of the time you would not like to do this, and it
prohibits easy ways to grep sources. OTOH, I guess this example is handled
well by emacs, as it probably detects the name of the method at least in two
different ways; def method_name and obj.method_name.

IMO, on some cases there really is no ambiguity what the code means, and the
simplest cases of those should be exploitable.

This actually goes nicely along with the naming conventions. The language is
of course a set of language rules, but it's also a set of more or less
standard conventions. These conventions include caSIng, accompanied test
suite, location of libraries. Some languages miss some features I consider
crucial, but no language contain all, as many times conventions counteract
or are simply contradictory.

Standard naming is defined for Java for example, but it's not forced. That
naming is actually quite much the same as in Ruby (the principle of
least...) and in many other major languages nowadays. Java defines also
reserved words, and *forces* they are not used as identifiers.

Well, Ruby simply takes different approach. It forces something about
naming, and does not force one not to mess up with reserved words - when
possible. I'd like to free up the name forcing too, trusting on a developer.
But here's a catch. We get something when trading off freedom of
individually styled naming. We don't have to find out where the variable
should be defined. It's global if has '$', it may be a CONSTANT, or
@instance_variable or @@class_variable. 

Surely @attribute is easier to write than self.attribute. But if you think
latter is so much more beautiful, use latter (and define the accessors,
which is good idea anyway :). If you can stand being a little bit ambiguate
use plain 'attribute'. 

Please reconsider the last paragraph, look again which was the only case I
had to explicitly mark which part of the sentence is 'code' :).

However, while it might sound I'm quite much pro Ruby, I'd like to give up
some forcing. One might be able to do like this:

  global :foo
  def bar
    puts foo
  end

And when Ruby is checking out what the foo might be inside bar, it sees
there's only global definition, and applies that. If this is good, it's hard
to say, as adding foo variable somewhere might confuse things up. So if you
really want to say 'puts $foo' it's explicitly expressed this way.

    - Aleksi