Garden RubyNuby Question on parameters in blocks vs. methods

ruby-talk
1

Noticed a new question on the RubyNuby page of the Garden Wiki.

"Why is method parameter syntax different from block parameter syntax?
Why not def foo |x| ... or do (a, b=1) ... ? (The question is not where
the notation came from; the question is, why are parameter lists not
the same in every context?)"

Seems to me there are at least a couple of parts to this question 1)
why the syntax differs and 2) why the parameter lists do not work
exactly the same.

T.

2

I'm suprised that no one is offering an answer here, especially
considering what's being said about the community's support of Nuby's
in other threads.

Well, I'll take a small stab at the 2nd. Please correct me in so far as
I am wrong: In future versions of Ruby block parameters and def
parameters will work exaclty alike.

As for the first. Why not "do (a,b) ... end" instead of "do |a,b| ...
end" Well, without thinking about it to much, I imagine it is simply
due to syntax ambiguities.

T.

3

I'm suprised that no one is offering an answer here, especially
considering what's being said about the community's support of Nuby's
in other threads.

Sorry, Trans, I just think that there are so many people on this list
that everyone figures someone else will answer.

That said, your original post isn't _that_ old. If you're looking for
real-time help, go to #ruby-lang on irc.freenode.net.

Well, I'll take a small stab at the 2nd. Please correct me in so far as
I am wrong: In future versions of Ruby block parameters and def
parameters will work exaclty alike.

Although I think 1.9 will make them work more similarly that they do
now, I don't think they will ever work exactly alike. You can do some
stuff with block parameters that's pretty crazy. For example, you
don't have to 'accept' the arguments passed in:

def doit
  yield(1)
end

doit { puts "Look ma, no arguments!" }

And you can expand arrays:

def pass_array
  yield([1,2])
end

pass_array {|(first, second)| puts "First element: #{first}"}

I haven't seen anything that says that methods will have this same
behavior (although they can do some of the same things using different
syntax) Anyone else?

As for the first. Why not "do (a,b) ... end" instead of "do |a,b| ...
end" Well, without thinking about it to much, I imagine it is simply
due to syntax ambiguities.

I've wondered about this one before. It would be _possible_ to change
the method definition to use pipes instead of parans, and not have
ambiguities (I think), but that's a pretty significant language
change. I guess they were just born that way, and it's too late to
change.

So, anyone else?

Dan

4

So these two would be the same, right?

def myfunc(foo = nil, bar = nil)
end

def myfunc |foo, bar|
end

Just a bit of sugar, I like it :slight_smile:

Douglas

···

On Apr 6, 2005 4:11 AM, Daniel Amelang <daniel.amelang@gmail.com> wrote:

> As for the first. Why not "do (a,b) ... end" instead of "do |a,b| ...
> end" Well, without thinking about it to much, I imagine it is simply
> due to syntax ambiguities.

I've wondered about this one before. It would be _possible_ to change
the method definition to use pipes instead of parans, and not have
ambiguities (I think), but that's a pretty significant language
change. I guess they were just born that way, and it's too late to
change.

5

Daniel Amelang wrote:

Sorry, Trans, I just think that there are so many people on this list
that everyone figures someone else will answer.

Yes, no doubt that's happening. Guess that's why I chirped up bit.

That said, your original post isn't _that_ old. If you're looking for
real-time help, go to #ruby-lang on irc.freenode.net.

Oh, its not so much for me, though I have wondered about it myself in
the past. It was a post on the Nuby page at Garden Wiki.... actually
there are a number of questions there still waiting for an answer. I
just noticed that someone posted a new one and I thought that maybe it
would be good to work on them so I posted it here. See:

  Captcha

Thanks for answering. You inspired some others too. I'll post a general
response based on these posts to the wiki when the thread's done.

Although I think 1.9 will make them work more similarly that they do
now, I don't think they will ever work exactly alike. You can do some
stuff with block parameters that's pretty crazy. For example, you
don't have to 'accept' the arguments passed in:

def doit
  yield(1)
end

doit { puts "Look ma, no arguments!" }

Okay, so your syaing differences will remain b/c of how methods handle
blocks --blocks of course can't take blocks in the same manner.

And you can expand arrays:

def pass_array
  yield([1,2])
end

pass_array {|(first, second)| puts "First element: #{first}"}

Hmmm... the notation does allow for this additional functionality.
Though I suspect this developed after the fact (i.e. after pipes were
decided upon) but I'm not sure.

I haven't seen anything that says that methods will have this same
behavior (although they can do some of the same things using

different

syntax) Anyone else?

> As for the first. Why not "do (a,b) ... end" instead of "do |a,b|

....

> end" Well, without thinking about it to much, I imagine it is

simply

> due to syntax ambiguities.

I've wondered about this one before. It would be _possible_ to change
the method definition to use pipes instead of parans, and not have
ambiguities (I think), but that's a pretty significant language
change. I guess they were just born that way, and it's too late to
change.

But the other way around?

  amethod { (x, y) puts "#{x} , #{y}" }

That does seem ambiguious.

T.

6

Hi --

···

On Wed, 6 Apr 2005, Douglas Livingstone wrote:

On Apr 6, 2005 4:11 AM, Daniel Amelang <daniel.amelang@gmail.com> wrote:

As for the first. Why not "do (a,b) ... end" instead of "do |a,b| ...
end" Well, without thinking about it to much, I imagine it is simply
due to syntax ambiguities.

I've wondered about this one before. It would be _possible_ to change
the method definition to use pipes instead of parans, and not have
ambiguities (I think), but that's a pretty significant language
change. I guess they were just born that way, and it's too late to
change.

So these two would be the same, right?

def myfunc(foo = nil, bar = nil)
end

def myfunc |foo, bar|
end

Hopefully it would be one or the other (the second only if there were
some huge unification going on where parens were eliminated for method
definitions).

David

--
David A. Black
dblack@wobblini.net

7

Oh I alsmost forgot. What about defualt parameters? Will blocks have
those in the future?

T.

8

The def method(params) is the style used in many commonly used
languages, such as 'C' and variants, 'VB' and so-on. So this style is
natural to me.

I think one of the attractions of Ruby is it's friendly looking
syntax. ie. a newcomer takes a look at a bit of ruby and thinks "hey,
that doesn't look too hard" and digs deeper.

Whereas if you take a look at, for example, Smalltalk, which (IMO)
looks a bit weird if you don't know how to read it, then this can be
quite offputting to newcomers.

Just my pointless 2 pence/cents/euros/sheckles worth.

···

On Apr 6, 2005 3:23 PM, David A. Black <dblack@wobblini.net> wrote:

Hi --

On Wed, 6 Apr 2005, Douglas Livingstone wrote:

> On Apr 6, 2005 4:11 AM, Daniel Amelang <daniel.amelang@gmail.com> wrote:
>>> As for the first. Why not "do (a,b) ... end" instead of "do |a,b| ...
>>> end" Well, without thinking about it to much, I imagine it is simply
>>> due to syntax ambiguities.
>>
>> I've wondered about this one before. It would be _possible_ to change
>> the method definition to use pipes instead of parans, and not have
>> ambiguities (I think), but that's a pretty significant language
>> change. I guess they were just born that way, and it's too late to
>> change.
>
> So these two would be the same, right?
>
> def myfunc(foo = nil, bar = nil)
> end
>
> def myfunc |foo, bar|
> end

Hopefully it would be one or the other (the second only if there were
some huge unification going on where parens were eliminated for method
definitions).

David

--
David A. Black
dblack@wobblini.net

--

All the best
Glenn
Aylesbury, UK

9

Oh I alsmost forgot. What about defualt parameters? Will blocks have
those in the future?

I don't know, good question. Only matz and the other ruby-dev's would
know that one, I think. The current development version of ruby (1.9)
doesn't allow them (I just tried it out).

But the other way around?
amethod { (x, y) puts "#{x} , #{y}" }
That does seem ambiguious.

Does to me, too.

I think the unification would have to be on the |pipes|. And as David
(who's always excited to see change in ruby :slight_smile: pointed out, it would
be a huge change. Probably not going to happen.

(From someone else's earier post)

So these two would be the same, right?
def myfunc(foo = nil, bar = nil); end
def myfunc |foo, bar|; end

So how would you enforce that foo and bar are passed in as parameters
(not optional)? Throw an exception if foo is nil? Check each required
one yourself? Hmm...it's nice to have ruby do that for you.

Dan