Method as first class member

[Guoliang Cao]

Hi,

I don't consider myself a ruby guru but have been a ruby user for a few
years. Since ruby 1.9 is out but its feature set is not finalized, guess
it's ok to voice my opinions on what may be interesting to a joe user.

Currently Ruby has 2 kinds of callable block - proc and lambda, which
are slightly different on semantics. Other than those, is it possible to
make methods work similarly (maybe like a lambda plus an implicit self
parameter)? This will make it closer to the statement "everything is an
object" - a method is an object too. This also makes Ruby a next level
functional language I guess. To refer to the method object, we probably
can use syntax like this:

m = obj->do_something
m[1,2,3]

m = Dir->pwd
m[]

Method object may work similar to lambda and be passed as parameter.
Down the way, partial invocation can be added by associating a context
to the method object and memorizing parameter values. i.e.

m = obj->do_something 1,2,3
m[]


What do you guys think? any comments are welcome.

Regards,
Guoliang

btw, I know ruby-core is the place to post but I don't have permission.
I wonder how the permission is granted, by number of posts?

 

[Robert Klemme]

Hi,

I don't consider myself a ruby guru but have been a ruby user for a few
years. Since ruby 1.9 is out but its feature set is not finalized, guess
it's ok to voice my opinions on what may be interesting to a joe user.

Currently Ruby has 2 kinds of callable block - proc and lambda, which
are slightly different on semantics. Other than those, is it possible to
make methods work similarly (maybe like a lambda plus an implicit self
parameter)? This will make it closer to the statement "everything is an
object" - a method is an object too. This also makes Ruby a next level
functional language I guess. To refer to the method object, we probably
can use syntax like this:

m = obj->do_something
m[1,2,3]

m = Dir->pwd
m[]

This does exist already although the syntax is slightly different:

irb(main):003:0> RUBY_VERSION
=> "1.8.5"
irb(main):004:0> m = "foo".method :length
=> #<Method: String#length>
irb(main):005:0> m.call
=> 3
irb(main):006:0> m = String.instance_method :length
=> #<UnboundMethod: String#length>
irb(main):007:0> m.bind("foo").call
=> 3
irb(main):008:0> m.bind("foo")
=> #<Method: String#length>
irb(main):009:0> m.bind("foo")[]
=> 3
irb(main):010:0> m = "foo".method<<)
=> #<Method: String#<<>
irb(main):011:0> m["bar"]
=> "foobar"
irb(main):012:0>

Note also that you can achieve something similar via send and this is
often sufficient.

Method object may work similar to lambda and be passed as parameter.
Down the way, partial invocation can be added by associating a context
to the method object and memorizing parameter values. i.e.

m = obj->do_something 1,2,3
m[]

This is only possible using lambdas AFAIK, i.e. you cannot stick method
parameters into a method.

What do you guys think? any comments are welcome.

With these questions I always ask myself what do we gain by such a
change? All changes have some effort attached, some more and some less.
But it's not worthwhile if the effort outweighs the benefits. What do
you think are the benefits of this change? Why should we do it?

Kind regards

robert

 

[Guoliang Cao]

object" - a method is an object too. This also makes Ruby a next level
functional language I guess. To refer to the method object, we probably
can use syntax like this:

m = obj->do_something
m[1,2,3]

m = Dir->pwd
m[]

This does exist already although the syntax is slightly different:

irb(main):003:0> RUBY_VERSION
=> "1.8.5"
irb(main):004:0> m = "foo".method :length
=> #<Method: String#length>
irb(main):005:0> m.call
=> 3
irb(main):006:0> m = String.instance_method :length
=> #<UnboundMethod: String#length>
irb(main):007:0> m.bind("foo").call
=> 3
irb(main):008:0> m.bind("foo")
=> #<Method: String#length>
irb(main):009:0> m.bind("foo")[]
=> 3
irb(main):010:0> m = "foo".method<<)
=> #<Method: String#<<>
irb(main):011:0> m["bar"]
=> "foobar"
irb(main):012:0>

Note also that you can achieve something similar via send and this is
often sufficient.

Thank you for replying. I'm aware of those even though I didn't use them
so far. "Methods are objects" are true. I'd better rephrase my
suggestion as a syntax sugar or enhancement.

Method object may work similar to lambda and be passed as parameter.
Down the way, partial invocation can be added by associating a context
to the method object and memorizing parameter values. i.e.

m = obj->do_something 1,2,3
m[]

This is only possible using lambdas AFAIK, i.e. you cannot stick method
parameters into a method.

What do you guys think? any comments are welcome.

With these questions I always ask myself what do we gain by such a
change? All changes have some effort attached, some more and some less.
But it's not worthwhile if the effort outweighs the benefits. What do
you think are the benefits of this change? Why should we do it?

I believe we get shorter, more intuitive code with this kind of syntax,
and partial invocation can help DRY in a lot of cases. Compare below
examples, what do you prefer? IMHO, the former syntax attracts
programmers to use, the latter is like, do this if you have to(this may
not be a bad thing though)

"foo"->length
"foo".method :length

I do agree changes require efforts and also add learning burden to
users, language designers/implementers have to be very careful with any
change to the language. However, most programmers have a dream - a
perfect language. Even it may not become true, we are closer than ever.
Do you agree?

 

[Robert Klemme]

Robert Klemme wrote:

I believe we get shorter, more intuitive code with this kind of syntax,
and partial invocation can help DRY in a lot of cases. Compare below
examples, what do you prefer? IMHO, the former syntax attracts
programmers to use, the latter is like, do this if you have to(this may
not be a bad thing though)

"foo"->length
"foo".method :length

How often is this used? I rarely see this so I would say, don' t
bother. Also, sometimes it can be helpful to be more verbose to
clarify that something special is happening there. Also, having a
rusty C and C++ background I would expect the first syntax to actually
execute the method and not return a meta data object.

Partial specialization might be a different story but I did not have
use for that either. IMHO making Ruby a functional language does not
work too well. And actually you *can* have partial specialization
with lambdas.

I do agree changes require efforts and also add learning burden to
users, language designers/implementers have to be very careful with any
change to the language. However, most programmers have a dream - a
perfect language. Even it may not become true, we are closer than ever.
Do you agree?

No. I for my part do not dream of a perfect language because I do not
believe something like that is possible. Also, I do not believe that
your proposed change would be an improvement worthwhile considering.
I prefer to use Ruby the way it is vs. worrying too much about
improvements.

Kind regards

robert

 

[Guoliang Cao]

Partial specialization might be a different story but I did not have
use for that either. IMHO making Ruby a functional language does not
work too well. And actually you *can* have partial specialization
with lambdas.

I posted a lambda based rough implementation a few weeks back

For many small features like currying, partial invocation, if they are
made easy, people will use. Otherwise, people don't bother.

No. I for my part do not dream of a perfect language because I do not
believe something like that is possible. Also, I do not believe that
your proposed change would be an improvement worthwhile considering.
I prefer to use Ruby the way it is vs. worrying too much about
improvements.

That's fine. I just wanted to throw out some rough opinions and become
thoughtful discussion. '->' definitely is questionable. However partial
invocation and method as objects are worth discussed in general.

Just be curious, don't you have any feature you would like to see in
Ruby 1.9/2.0?

Regards,
Guoliang

 

[Robert Dober]

How often is this used?

Far too rarely I believe, there was a recent tread in which David
Black suggested the :: syntax for method retrieval and . for a method
call
e.g.
o.m(42) the same as
o::m.call(42)
although there was a different syntax for call discussed too but I
honestly do not remember - I was voting for .call so my memory is
biased .
I believe that we would see this kind of application quite often

some_method_needing_a_block &o::m
instead of
some_method_needing_a_block { |o| o.m }

Anyway your conservative POV is also very understandable but for
metaprogrammers and DSL writers it would be a *convenient* feature.
I do not daresay if this is reason enough, maybe somebody should take
the bull by the horns and write an RCR to get some voting, alas there
is no voting feature right now, only replys to the RCR on ruby::core


f I rarely see this so I would say, don' t

bother. Also, sometimes it can be helpful to be more verbose to
clarify that something special is happening there. Also, having a
rusty C and C++ background I would expect the first syntax to actually
execute the method and not return a meta data object.

Partial specialization might be a different story but I did not have
use for that either. IMHO making Ruby a functional language does not
work too well. And actually you *can* have partial specialization
with lambdas.

Well I would like to have the feature (because I am greedy) but I do
not see usecases, IIRC Facets has something like this, Functors, but I
am not 100% sure.I guess perfection can only reached asymptotically, meaning huger
efforts for less improvement the closer one gets, but this is a very
private theory of mine - or did I steal it from Relativity? Yes, pretty much, even if this makes a mess ( one Robert agrees the
other not, but Roberts are organized democratically
"Perfect" however is very personal and may vary with time and needs,
we are surely dreaming a little bit, I have to admit.

No. I for my part do not dream of a perfect language because I do not
believe something like that is possible. Also, I do not believe that
your proposed change would be an improvement worthwhile considering.
I prefer to use Ruby the way it is vs. worrying too much about
improvements.

Sure enough, but you risk not to like some of the changes in 1.9 so
maybe a little bit of soft lobbying for features one likes seems to be
in order.BTW a thing I wanted to say about your sig for a long time now: "I'd
loved to have this idea before you did"
Cheers
Robert

 

[Robert Klemme]

Far too rarely I believe, there was a recent tread in which David
Black suggested the :: syntax for method retrieval and . for a method
call
e.g.
o.m(42) the same as
o::m.call(42)
although there was a different syntax for call discussed too but I
honestly do not remember - I was voting for .call so my memory is
biased .
I believe that we would see this kind of application quite often

I definitively think that #call should be retained - simply because
method objects support it right now (along with #[]) and lambdas do it
as well. This makes for good duck typing and makes learning and code
migration easier.

some_method_needing_a_block &o::m
instead of
some_method_needing_a_block { |o| o.m }

Anyway your conservative POV is also very understandable but for
metaprogrammers and DSL writers it would be a *convenient* feature.

I would have thought that with metaprogramming these places are rare.
You typically do not run around and have 50 places in a framework that
need this. I'd estimate that in reality there would be only so few
places - which is logical since metaprogramming usually adds some
generic feature (just think about how #method_missing is implemented
only once per interface or class).

I do not daresay if this is reason enough, maybe somebody should take
the bull by the horns and write an RCR to get some voting, alas there
is no voting feature right now, only replys to the RCR on ruby::core

Yep.


Well I would like to have the feature (because I am greedy)

Ha! I tend to get motivation from simplification. I believe less is
more. (btw, some engineers seem to feel in a similar way:
http://www.zeit.de/2008/21/Autobilligmacher?page=all)

but I do
not see usecases, IIRC Facets has something like this, Functors, but I
am not 100% sure.
I guess perfection can only reached asymptotically, meaning huger
efforts for less improvement the closer one gets, but this is a very
private theory of mine - or did I steal it from Relativity?
Yes, pretty much, even if this makes a mess ( one Robert agrees the
other not, but Roberts are organized democratically

That's for sure - good, old European democracy! ;-)

"Perfect" however is very personal and may vary with time and needs,
we are surely dreaming a little bit, I have to admit.

That's my main criticism of the term: perfect according to what
standards? The "perfect" language would make *all* implementation tasks
easy, wouldn't it? But then it would probably contain a standard
library with solutions for everything. And then there is the question
whether making one thing work good will leave others unchanged - my
intuition tells me that usually optimizing for one feature will
sacrifice others. In the real world you always pay a price.

Sure enough, but you risk not to like some of the changes in 1.9 so
maybe a little bit of soft lobbying for features one likes seems to be
in order.

We'll see. I know that I will like the new regexp engine (apart from
its name which I always keep forgetting maybe).

BTW a thing I wanted to say about your sig for a long time now: "I'd
loved to have this idea before you did"

LOL - thank you!

Whereof one cannot speak, thereof one must be silent.
Ludwig Wittgenstein

A wise man. And apparently also a friend of simplification - less is
more.

Good night

robert

 

[Robert Dober]

A wise man. And apparently also a friend of simplification - less is more.
Yes but there is also Einstein's:
As simple as possible, *but not simpler*.
I however admit that the probability of Ruby being simpler as possible
is approximately 42/42 - 42**0

Cheers
Robert