Def blah do |x| -- alternate method definition syntax

Hi all,

This came up in a discussion about Ruby with a friend who is learning…

Why aren’t method definitions more like blocks? Perhaps it’s easier to
explain with some examples. Consider the method blah:

def blah(x)

end

And this proc:

lambda do |x|

end

Friend wondered why a method definition couldn’t be like this:

def blah do |x|

end

And I didn’t have a good answer, except that “it just is.” Maybe I
could have gone into the semantic difference between methods and
lambda procs, but does semantic difference necessitate syntactic
difference?

I tried to simulate this like so:

blah = lambda do |x|

end

Which I realize is going down a different path, but still. Now I wish
I could do this:

blah(5)

But I can’t. I have to blah.call.

I’m not complaining at all. This isn’t bait. It’s just me loving Ruby
and wondering aloud. Any opinions?

Joe

Hi,

In message “Re: def blah do |x| – alternate method definition syntax”
on Mon, 5 Nov 2007 14:07:21 +0900, Joe H. [email protected]
writes:

|Friend wondered why a method definition couldn’t be like this:
|
|def blah do |x|
| …
|end

This syntax disallows optional arguments. We can’t just parse them.
If you really want to define a method with block parameter style, you
can do:

define_method(:blah) do |x|

end

Almost same, isn’t it?

          matz.

On 11/5/07, Joe H. [email protected] wrote:

Joe

You don’t have to do blah.call, you can do blah[5] which is pretty close
:slight_smile:

Quoth Joe H.:

end
end

Joe

blah.call(5) is synonymous with blah[5], IIRC.

HTH,

Apologies…

Somehow i quoted myself out:

You don’t have to do blah.call, you can do blah[5] which is pretty close
:slight_smile:

On 11/5/07, Joe H. [email protected] wrote:

Thanks matz and all. The define_method() trick hadn’t occurred to me
– almost the same, indeed. Why couldn’t block parameter syntax be
extended to accept optional args: do |x, y=0| ? I Realize that this is
only meaningful for the hypothetical def usage, but come to think of
it I see no reason blocks couldn’t accept optional args in cases where
they’re .called().

And doesn’t calling a proc with [] smell like a cute hack (hey, we’ve
got this bracket method…) to anyone else?

Nope. Not something that seems odd at all after five years of using
Ruby. :wink:

-austin

On Nov 5, 4:59 am, [email protected] wrote:

Thanks matz and all. The define_method() trick hadn’t occurred to me
– almost the same, indeed. Why couldn’t block parameter syntax be
extended to accept optional args: do |x, y=0| ? I Realize that this is
only meaningful for the hypothetical def usage, but come to think of
it I see no reason blocks couldn’t accept optional args in cases where
they’re .called().

Because the | operator exists, and there are some edge cases where it
would be hard to determine when the block had ended. Something like:

foo{ |x, y=0| 1+6|7 }

could be either:
foo{ |x, y=0| (1+6|7) }
or
foo{ |x, y=((0|1)+6)| 7 }

IIRC, it’s not just that such edge cases exist (where a sane human
could possibly make a choice to disallow certain otherwise-legal
syntax), but that it’s very hard or impossible to adjust the syntax
lexer to allow them.

Thanks matz and all. The define_method() trick hadn’t occurred to me
– almost the same, indeed. Why couldn’t block parameter syntax be
extended to accept optional args: do |x, y=0| ? I Realize that this is
only meaningful for the hypothetical def usage, but come to think of
it I see no reason blocks couldn’t accept optional args in cases where
they’re .called().

And doesn’t calling a proc with [] smell like a cute hack (hey, we’ve
got this bracket method…) to anyone else?

On 11/5/07, Joe H. [email protected] wrote:

Thanks matz and all. The define_method() trick hadn’t occurred to me
– almost the same, indeed. Why couldn’t block parameter syntax be
extended to accept optional args: do |x, y=0| ? I Realize that this is
only meaningful for the hypothetical def usage,
not at all, it is very useful and will therefore be part of Ruby1.9
but come to think of
it I see no reason blocks couldn’t accept optional args in cases where
they’re .called().
Neither did Matz :wink:

Robert

On 11/5/07, Phrogz [email protected] wrote:

syntax), but that it’s very hard or impossible to adjust the syntax
lexer to allow them.
ooops, sorry I was replying to the wrong question

foo { |x,*args,&blk| } will be part of Ruby1.9 and not
foo{ |x,y=42|}
OP can you please post questions that correspond to my answers? Ty very
much :wink:
R.

I think its almost perfect the way it is, but i would really enjoy
blocks
with optional parameters.

|def blah do |x|
| …
|end

Would it be possible, hypothetically speaking, to make the parser
digest something like:

def bla do(x, y=1, z=2)
    ...
end

and (maybe instead of or additionally to the experimental -> syntax)

a = arr.map def(x, y=1) ... end

fn = def(x, y=1) ... end

or

a = arr.map do(x, y=1) ... end

fn = do(x, y=1) ... end

I personally am not very fond of curly braces, vertical bars, and
arrows. Maybe it’s because I learned Pascal first.