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

ruby-talk
1

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

2

Hi,

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.

···

In message "Re: def blah do |x| -- alternate method definition syntax" on Mon, 5 Nov 2007 14:07:21 +0900, Joe Holt <joe07734@gmail.com> writes:

3

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

···

On 11/5/07, Joe Holt <joe07734@gmail.com> wrote:

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

4

Quoth Joe Holt:

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

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

HTH,

···

--
Konrad Meyer <konrad@tylerc.org> http://konrad.sobertillnoon.com/

5

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, Dan <dan.macdaddy+ruby@gmail.com> wrote:

On 11/5/07, Joe Holt <joe07734@gmail.com> wrote:

>
> 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
>
>
>

6

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 Nov 5, 2007, at 12:24 AM, Yukihiro Matsumoto wrote:

Hi,

In message "Re: def blah do |x| -- alternate method definition syntax" > on Mon, 5 Nov 2007 14:07:21 +0900, Joe Holt <joe07734@gmail.com> > 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.

7

>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.

8

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

-austin

···

On 11/5/07, Joe Holt <joe07734@gmail.com> 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?

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

9

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.

···

On Nov 5, 4:59 am, joe07...@gmail.com 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().

10

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:

<snip>

Robert

···

On 11/5/07, Joe Holt <joe07734@gmail.com> wrote:

--
what do I think about Ruby?
http://ruby-smalltalk.blogspot.com/

11

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

···

--
Bernardo Rufino

12

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.

···

On 11/5/07, Phrogz <phrogz@mac.com> wrote:

On Nov 5, 4:59 am, joe07...@gmail.com 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.

--
what do I think about Ruby?
http://ruby-smalltalk.blogspot.com/