Default argument values for blocks

[Ara.T.Howard]

Hi,

In message "Re: Default argument values for blocks"

|Hey, what about "foo="bar"){puts foo}"? It's still not beautiful but it's
|still less annoying, and in Ruby we are already used to see colons at the
|beginning of a word. Of course, overloading ":" may not be considered a good
|idea, but it shouldn't be a parsing problem as this one would always be
|followed by a "(" (and that doesn't happen with symbols). And:
|
|collection.eachfoo="bar"){puts foo}
|
|isn't that bad .

I have never thought of that. Hmm, let me think about it during the
conference trip. I'm leaving tomorrow morning.

but

method bool ? 42 : (0b101010) { "block" }

is valid now.

':' is nice on the eyes though. maybe '::'

-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| Your life dwells amoung the causes of death
| Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================

 

[Hugh Sasse]

but

method bool ? 42 : (0b101010) { "block" }

is valid now.

':' is nice on the eyes though. maybe '::'

maybe :-(foo = "bar") {...}, where :-( is pronounced "sadly"SCNR,
Hugh

 

[Eric Mahurin]

Hi,
=20
In message "Re: Default argument values for blocks"
on Wed, 12 Oct 2005 20:42:06 +0900, Christophe Grandsire
=20
|Hey, what about "foo=3D"bar"){puts foo}"? It's still not
beautiful but it's
|still less annoying, and in Ruby we are already used to see
colons at the
|beginning of a word. Of course, overloading ":" may not be
considered a good
|idea, but it shouldn't be a parsing problem as this one
would always be
|followed by a "(" (and that doesn't happen with symbols).
And:
|
|collection.eachfoo=3D"bar"){puts foo}
|
|isn't that bad .
=20
I have never thought of that. Hmm, let me think about it
during the
conference trip. I'm leaving tomorrow morning.

Here's another one:

f =3D .(foo=3D"bar"){puts foo}

collection.each.(foo=3D"bar){puts foo}

"." is already used for method call, so why not lambda/block
definition? I don't think this would collide with anything
because an identifier should normally follow "." and we are
following it with "(" here.


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around=20
http://mail.yahoo.com=20

 

[Christophe Grandsire]

but d a
good

but

method bool ? 42 : (0b101010) { "block" }

is valid now.

Does it mean "method(bool ? 42 : (0b101010)) { "block"}"? It looks so str=
ange I
don't know how to parse it. Also, doesn't the presence of the "?" make th=
e ":"
unambiguous in this case? Just asking, I really don't know.
--
Christophe Grandsire.

http://rainbow.conlang.free.fr

It takes a straight mind to create a twisted conlang.

 

[Ara.T.Howard]

Does it mean "method(bool ? 42 : (0b101010)) { "block"}"?
yes.

Also, doesn't the presence of the "?" make the ":" unambiguous in this case?
Just asking, I really don't know.

probably. i don't know either. just seem potentially confounding.

cheers.

-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| Your life dwells amoung the causes of death
| Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================

 

[Ezra Zygmuntowicz]

maybe :-(foo = "bar") {...}, where :-( is pronounced "sadly"

SCNR,
Hugh

What about:

~foo = "bar") {...}

?

-Ezra Zygmuntowicz
Yakima Herald-Republic
WebMaster
http://yakimaherald.com
509-577-7732
(e-mail address removed)

 

[James Edward Gray II]

Here's another one:

f = .(foo="bar"){puts foo}

collection.each.(foo="bar){puts foo}

"." is already used for method call, so why not lambda/block
definition? I don't think this would collide with anything
because an identifier should normally follow "." and we are
following it with "(" here.

Ooo, I kind-of like that...

James Edward Gray II

 

[Christophe Grandsire]

En r=E9ponse =E0 Eric Mahurin :

=20
=20
Here's another one:
=20
f =3D .(foo=3D"bar"){puts foo}
=20
collection.each.(foo=3D"bar){puts foo}
=20
"." is already used for method call, so why not lambda/block
definition? I don't think this would collide with anything
because an identifier should normally follow "." and we are
following it with "(" here.
=20

Although I find it kind of attractive, I am concerned about the=20
overloading of ".", which all in all is a bit small to have much=20
meaning. I'm afraid it would get unnoticed. ":" I think wouldn't, and=20
there's already a precedent in Ruby of having a construction begin with=20
":" (namely symbols). So I kind of like it, but am wondering about its=20
readability. ":" is similar, but has a higher weight, and is thus better=20
noticed.

But if my proposal gets struck down, I'll be the first to vote for=20
yours, since "\" kind of was refused by matz himself because of font issu=
es.
--=20
Christophe Grandsire.

http://rainbow.conlang.free.fr

You need a straight mind to invent a twisted conlang.

 

[ES]

I have and can only concur. The arrows make things pretty confusing in most
places.




The problem is that "collection.each lambda(foo="bar") {puts foo}" has to be the
ugliest and most long-winded thing I've seen in a long time. It's OK for making
a Proc, but to use as a block it's just plain wrong.

So do not use it as a block. This syntax only solves the default args (etc.)
problem but does not in any way invalidate the block syntax (which, as Matz
has pointed out many times, is not going anywhere).

collection.each {|foo| puts foo}

and

block = lambda(foo = 'bar') { puts foo }

However, it's nearly impossible a problem to solve. Any solution will probably
look rather awful. We just need to find the least offensive one . Unless one
finds a way to parse "{|foo="bar"| puts foo}" correctly. That'd be the best
solution.




Hasn't a change been accepted that allows one to use ":" as an alternative to
"=>" in hashes?

Hey, what about "foo="bar"){puts foo}"? It's still not beautiful but it's
still less annoying, and in Ruby we are already used to see colons at the
beginning of a word. Of course, overloading ":" may not be considered a good
idea, but it shouldn't be a parsing problem as this one would always be
followed by a "(" (and that doesn't happen with symbols). And:

collection.eachfoo="bar"){puts foo}

isn't that bad .

E

 

[Christophe Grandsire]

En r=E9ponse =E0 Ara.T.Howard :

=20
=20
yes.
=20

Difficult to parse indeed...

=20
probably. i don't know either. just seem potentially confounding.
=20

I'd say it has the same potential of confusion as symbols, since you can=20
have both ":name" and "bool ? 42 : name". If this isn't considered an=20
issue (and it seems it isn't ), I don't think my proposal would be=20
one either. Otherwise, I think Eric's proposal might be an idea too=20
(although in this case *I* am concerned about possibilities of confusion=20
by lack of notice of the symbol).

But matz said he would think about it. I'm really honoured already, and=20
I don't mind that much if it doesn't make it, as long as we get an=20
aesthetic and practical syntax.
--=20
Christophe Grandsire.

http://rainbow.conlang.free.fr

You need a straight mind to invent a twisted conlang.

 

[Christophe Grandsire]

En r=E9ponse =E0 Yukihiro Matsumoto :

|
|collection.eachfoo=3D"bar"){puts foo}
|
|isn't that bad .
=20
I have never thought of that. Hmm, let me think about it during the
conference trip. I'm leaving tomorrow morning.
=20
matz.
=20

I'm really honoured that you're considering my proposal. I can hardly=20
wait to know what your opinion is!
--=20
Christophe Grandsire.

http://rainbow.conlang.free.fr

You need a straight mind to invent a twisted conlang.

 

[Sean O'Halpin]

but

method bool ? 42 : (0b101010) { "block" }

is valid now.

Hmmm... this is what I get. Have I missed something?

def method(bool)
bool
end

method true ? 42 : (0b101010) { "block" }
method false ? 42 : (0b101010) { "block" }

__END__
block-syntax.rb:5: syntax error
method true ? 42 : (0b101010) { "block" }
^
(The "^" points at the space after the "{" )

Regards,

Sean

 

[Sean O'Halpin]

Or maybe if "eval" became a keyword like you mentioned above
and it could also take a block, you could do this instead:

b=3D1
eval {|;b|
b=3D5
p b # =3D> 5
}
p b # =3D> 1

+1

Any chance of eval taking a block ~and~ a specific binding, e.g.

eval &block, binding

(though this breaks current argument parsing rules).

Sean

 

[Ara.T.Howard]

+1

Any chance of eval taking a block ~and~ a specific binding, e.g.

eval &block, binding

(though this breaks current argument parsing rules).

Sean

eval(binding, &block) works. the eval(string) method just needs to check it's
arg type.

-a
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| Your life dwells amoung the causes of death
| Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================

 

[Eric Mahurin]

On Thu, 13 Oct 2005, Sean O'Halpin wrote:
=20
=20
eval(binding, &block) works. the eval(string) method just
needs to check it's
arg type.

It doesn't need to check type. If there is a block, the
optional arg would be a binding. Otherwise, the first arg is
the eval string and the optional second arg is the binding.

If this is possible, it would be good to be able to do this to
a general Proc. But, if not you could still make the
functionality with the above Kernel#eval:

class Proc
def rebind(binding)
Proc.new {
eval(binding,&self)
}
end
end

Of course you have the same problem that we have with
instance_eval - you can't pass any args. Might as well think
about making that work with eval too.




=09
__________________________________=20
Yahoo! Music Unlimited=20
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/

 

[David A. Black]

Hi --

However, it's nearly impossible a problem to solve. Any solution will probably
look rather awful. We just need to find the least offensive one . Unless one
finds a way to parse "{|foo="bar"| puts foo}" correctly. That'd be the best
solution.



Hasn't a change been accepted that allows one to use ":" as an alternative to
"=>" in hashes?

Hey, what about "foo="bar"){puts foo}"? It's still not beautiful but it's
still less annoying, and in Ruby we are already used to see colons at the
beginning of a word. Of course, overloading ":" may not be considered a good
idea, but it shouldn't be a parsing problem as this one would always be
followed by a "(" (and that doesn't happen with symbols). And:

collection.eachfoo="bar"){puts foo}

isn't that bad .

But it's so arbitrary. Surely there's no general principle of "being
used to" a given punctuation mark that makes it acceptable for
something like this.

I don't mean to jump on your idea specifically. The whole thread
seems to be about which arbitrary bit of punctuation might be least
ugly. I'm totally unconvinced that default values for block variables
are worth doing any of them.


David (in San Diego!

 

[Sean O'Halpin]

Agreed - I did think of that but for some reason I wasn't sure it felt
right. We'd have eval(string, binding) but eval(binding, &block).
Still, I guess anyone who wanted to use eval(binding, &block) would
probably know what they're doing! Both your and Eric's suggestions
have made me change my mind. I'm sure it would be easier to implement
this than to change Ruby's parser.

(BTW: Just in case anyone gets the wrong idea here, Ara is saying that
eval(binding, &block) doesn't break arg parsing rules - don't expect
this to actually ~work~ in Ruby 1.8.2!)

It doesn't need to check type. If there is a block, the
optional arg would be a binding. Otherwise, the first arg is
the eval string and the optional second arg is the binding.

If this is possible, it would be good to be able to do this to
a general Proc. But, if not you could still make the
functionality with the above Kernel#eval:

class Proc
def rebind(binding)
Proc.new {
eval(binding,&self)
}
end
end

Of course you have the same problem that we have with
instance_eval - you can't pass any args. Might as well think
about making that work with eval too.

For instance_eval, how about simply

instance_eval(*args, &block)

i.e. if it has a block, then the arguments are passed to it.
e.g.

instance_eval(1,2,3) {|a,b,c| ...}
instance_eval(1,2,3, &block)

If no block, then it would expect a string as it does now.

For eval, this could work the same way, with the first argument being
the binding, e.g.

eval(binding, 1,2,3) {|a,b,c| ... }

As Eric says, the distinguishing characteristic would be whether there
is a block or not.

Regards,

Sean

 

[Phil Tomson]

Hi --



But it's so arbitrary. Surely there's no general principle of "being
used to" a given punctuation mark that makes it acceptable for
something like this.

I don't mean to jump on your idea specifically. The whole thread
seems to be about which arbitrary bit of punctuation might be least
ugly. I'm totally unconvinced that default values for block variables
are worth doing any of them.

I totally agree, David. I can't believe that we're about to mess up
Ruby's syntax because someone asked for default values for block
variables. I hope this idea is really well discussed at Rubyconf. I
can't think of a time that I thought "you know, I really could use to
have default values for block variables". Since it is such a special
case and it's easy to work around I can't see messing with one of the
most recognizable bits or Ruby syntax (as in, if I see
"array.each{|foo| ... }" I know immediately I'm looking at Ruby code).

There's a discussion of this over at http://Redhanded.hobix.com where
the assumption seems to be that this proposed '->' syntax is going to
replace the current 'goalpost' syntax '{|..|}'. Someone please say
this isn't so.


Phil

 

[ES]

So do not use it as a block...

I am terribly sorry, that came out entirely too harsh. There was supposed
to be a smiley face right there!

...This syntax only solves the default args (etc.)
problem but does not in any way invalidate the block syntax (which, as Matz
has pointed out many times, is not going anywhere).

collection.each {|foo| puts foo}

and

block = lambda(foo = 'bar') { puts foo }

E

 

[Christophe Grandsire]

En r=E9ponse =E0 David A. Black :

=20
But it's so arbitrary. Surely there's no general principle of "being
used to" a given punctuation mark that makes it acceptable for
something like this.
=20

No, but do you really want to have "->" instead?

I don't mean to jump on your idea specifically. The whole thread
seems to be about which arbitrary bit of punctuation might be least
ugly. I'm totally unconvinced that default values for block variables
are worth doing any of them.
=20

The problem is that default values for blocks *are* now in Ruby 1.9, and=20
thus are probably going to be in Ruby2, and use right now the ugly "->".=20
If they are going to be there, let's have at least a non-intrusive=20
syntax. Yes it's arbitrary, but just as much as using : for symbols and=20
@ for instance variables. At the end of the day, every syntax in a=20
language is a matter of choice and convention, i.e. it's arbitrary.

I also don't really see why blocks arguments should have default values.=20
But if we're going to have them, at least let's have an OK syntax for=20
them, instead of an ugly beast.
--=20
Christophe Grandsire.

http://rainbow.conlang.free.fr

You need a straight mind to invent a twisted conlang.