«

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