From: "David A. Black" <dblack@...>
Date: 2004-08-06T13:52:55+09:00
Subject: Re: Macros in Ruby

Hi --

On Fri, 6 Aug 2004, Ara.T.Howard wrote:

> On Fri, 6 Aug 2004, Hal Fulton wrote:
> 
> > David A. Black wrote:
> >> Hi --
> >>
> <snip>
> >> I admit I'd opt for inconsistency over further punctuation in this
> >> case :-) But actually I'm not sure I'd agree that & in arglists is the
> >> same usage as & as synonym for lambda.  I've always thought of it as a
> >> kind of singular construct, necessary because the whole code-block
> >> thing has that singularity.  Also there's this:
> >>
> >>   pr = lambda {}
> >>   some_method &pr
> >>
> >> which would become
> >>
> >>   pr = &{}
> >>   some_method &pr
> >>
> >> which bugs me in some way involving levels of indirection that I can't
> >> quite put my finger on....
> >
> > I can't put my finger on it either, but I see your point. And that is
> > perhaps the best argument against it I've seen.
> 
> it's no stranger than this to me
> 
>    jib:~ > cat a.rb
> 
>    def method &block; m &block; end
>    def m &block; block.call; end
> 
>    method{ puts 42 }
> 
>    jib:~ > ruby a.rb
>    42
>
> and feels alot like
> 
>    const char *cp = "foobar";
>    printf ("%c\n", *cp);

(So your keyboard *does* have parens! :-)

I think this is different, in the sense that

   const char *cp;

declares "*cp" ("cp dereferenced by one level") to be of type const
char -- and then it's simply used that way.  So it's consistent; *cp
is always of the same type, and * always means the same thing.

It's true that the two &'s in your example mean different things, so
one could argue that there's strangeness.  But they're syntactically
quarantined from each other, so there's no unclarity.  

However, if & were a synonym for lambda, different &'s would start to
mingle unclearly with each other.  Specifically, & would then mean
both "make a Proc object from the following block" (lambda {}) and
"make a block from the following Proc object" (some_method &a_proc).
And then this:

  def some_method(*args)
  end

  some_method &{}

could be either

  some_method &lambda {}

or

  some_method(lambda {})

I know that parentheses for method arguments are being encouraged
(required?) in upcoming Rubies, but I still think this would end up
getting tied in knots.  To use another C analogy: it's almost like
using * and * instead of * and &, and counting on circumstantial or
semantic things to disambiguate them.  (Not an exact analogy but
indicative of what I think might be the problems.)


David

-- 
David A. Black
dblack@wobblini.net