From: George Ogata <g_ogata@...>
Date: 2004-07-08T17:22:35+09:00
Subject: Re: Array::index and rindex operator

"David A. Black" <dblack@wobblini.net> writes:

> On Wed, 7 Jul 2004, George Ogata wrote:
>
>> Well, one could also counter-argue that in the useless-block cases
>> it's not ambiguous, though I think ideally, ruby should still
>> complain.  I guess it doesn't due to a combination of ruby's dynamic
>> nature (it can't determine for itself whether or not a block might be
>> needed at compile time, and it's inefficient to check it at runtime),
>> and ruby's "no declarations" philosophy (i.e., no declaring "I take
>> blocks" in the method definition).  Perhaps also because a useless
>> block isn't an oft-made mistake.
>
> I'd rather not have a warning in the general case (i.e., imposed by
> the interpreter rather than by the method's own logic).  One might
> have something like:
>
>   def x
>     @cached ||= yield * 10
>   end
>
> where the yielding happens conditionally.  (Classically non-wonderful
> example, but still :-)

Well, that's what I meant by:

>> I guess it doesn't due to [...] ruby's dynamic nature (it can't
>> determine for itself whether or not a block might be needed at
>> compile time, and it's inefficient to check it at runtime)

In your example, it *could* actually see that there's a "yield" node
in the AST, but with things like #eval it's impossible.  (So it's
actually impossible at runtime too -- oops.)

So since the interpreter can't figure it out on it's own, you'd need
to give it a kick by providing some syntactic signal, e.g.:

def x &  # the '&' means "I can take a block"
  ## ... maybe yield ...
end

....but then ruby has a

>> "no declarations" philosophy (i.e., no declaring "I take blocks" in
>> the method definition).

So in the end all I'm saying is that in an Ideal Magical World of
Happiness (TM), I think it should complain, but I understand that it's
not really practical now.

>> As for the "left-to-right" view, there's no precedence for this being
>> silently ignored in the presence of ambiguity, is there?
>
> I don't think any existing methods do this; I'm really just
> speculating about whether or not it would make sense to write a method
> that way.  I think it would, at an abstract level, but having the
> method intervene if one calls it ambiguously also makes sense, perhaps
> more sense at the practical level.

Hmm, it'd be interesting to see.