On 5/31/07, Eleanor McHugh <eleanor / games-with-brains.com> wrote:
> 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
>
>
>
But maybe things should really by simple

return if x > 42
return unless (x+1)%2 == 0 # not zero? here

could probably made syntactically work (differently than now) and
return the LHS of the expression iff the expression evaluates to true
or false respectively.
Do I like it?
I said no above, but maybe I was wrong ;)
As a matter of fact I would like it if 90% of the Rubyist liked it as
this would take away the nasty taste of surprising behavior.
OTOH no evolution without surprise, can you imagine how surprised the
dinosaurs were after their extinction!

Cheers
Robert

-- 
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw