Paul Graham recommends Ruby

[David A. Black]

Hi --

a[1] works nicely for lambdas too, btw (not that I wouldn't like to see
a(1), of course).

Try the 1.9 cvs version:

irb(main):001:0> a = lambda { |x| x * 2 }
=> #<Proc:0xb7c6118c@(irb):1>
irb(main):002:0> a(1)
=> 2
irb(main):003:0> a 1
=> 2

I guess I spoke too soon in my last message.

I'm getting very confused by all of this, especially calling a lambda
with (). (I know it's a popular idea, is done in other languages,
etc. I mean I'm getting confused by how all these things fit into
Ruby.)

Matz: can you clarify where this is going?


David

 

[David A. Black]

Hi --

No yield:

def foo(x, y)
x.call
y.call
end

foo {|x|...}, {|y|...}

I don't think you can do that, without parentheses:

irb(main):008:0> def foo(x, y)
irb(main):009:1> x.call
irb(main):010:1> y.call
irb(main):011:1> end
=> nil
irb(main):012:0> foo {|| }, {|| }
SyntaxError: compile error
(irb):12: syntax error
foo {|| }, {|| }
^
(That's CVS from about 10 minutes ago


David

 

[Florian Frank]

Very sweet. How does this work, internally? Have lambdas been
specialcased at the interpreter level?

There is a NODE_LAMBDA now, but the () change seems to be independent
of the introduction of the f = { |x, y| x + y } syntax.

Internally a method call to variable 'a' is changed to a call to "call"
on the referenced object. This means, it's also possible to define call
methods in arbitrary objects or classes, like this:

class Hash
def call(x)
self[x]
end
end

fib = Hash.new do |f, i|
f = case i
when 0 then 0
when 1 then 1
else f(i - 1) + f(i - 2)
end
end
p fib(25)

 

[Yukihiro Matsumoto]

Hi,

In message "Re: Paul Graham recommends Ruby"

|Matz: can you clarify where this is going?

Nowhere. I'm just experimenting new syntax, such as

* a lambda without "lambda"
* call without "call"
* explicit block local variables
* etc.

They are fragile by nature. They might be removed in the future.

matz.

 

[Michael Campbell]

http://www.artima.com/weblogs/viewpost.jsp?thread=98196

But who cares?

From that article:

"filter(P, S) is almost always written clearer as [x for x in S if P(x)]"


Wow. He and I clearly have different views of "clear".

 

[Navindra Umanee]

I'm getting very confused by all of this, especially calling a lambda
with (). (I know it's a popular idea, is done in other languages,
etc. I mean I'm getting confused by how all these things fit into
Ruby.)

Why? It seems natural to call a function with ().

-N.

 

[vruz]

This thread was started because he seemed to be pushing Ruby. In any

case, Graham has his own agenda and will probably be pushing Arc if
it's ever released.

http://www.paulgraham.com/arc.html

You seem to really have a hard time believing someone IS pushing Ruby

 

[Navindra Umanee]

You seem to really have a hard time believing someone IS pushing Ruby

I honestly have no idea what you're talking about... I push Ruby
myself.

-N.

 

[Aredridel]

Hi,

In message "Re: Paul Graham recommends Ruby"

|Matz: can you clarify where this is going?

Nowhere. I'm just experimenting new syntax, such as

* a lambda without "lambda"
* call without "call"
* explicit block local variables
* etc.

They are fragile by nature. They might be removed in the future.

I rather like the idea of a lambda without lambda, and moreso the call
without #call. I can see the fragility, but I've wanted it. I'd love it
if it's possible without wrecking things.

 

[Kent Sibilev]

Hm, strange

irb(main):001:0> l = {|x| puts x*2}
=> #<Proc:0x00338710@(irb):1>
irb(main):002:0> l(2)
4
=> nil
irb(main):003:0> {|x| puts x*2}(2)
SyntaxError: compile error
(irb):3: parse error
{|x| puts x*2}(2)
^
from (irb):3

Kent.

a[1] works nicely for lambdas too, btw (not that I wouldn't like to see
a(1), of course).

Try the 1.9 cvs version:

irb(main):001:0> a = lambda { |x| x * 2 }
=> #<Proc:0xb7c6118c@(irb):1>
irb(main):002:0> a(1)
=> 2
irb(main):003:0> a 1
=> 2

 

[gabriele renzi]

Aredridel ha scritto:

I rather like the idea of a lambda without lambda, and moreso the call
without #call. I can see the fragility, but I've wanted it. I'd love it
if it's possible without wrecking things.

I agree, even if I think a little messing up it's ok, if the stuff that
gets broken is in remote corners. I don't expect ruby to be the same for
ever.

 

[Florian Gross]

Hm, strange

irb(main):001:0> l = {|x| puts x*2}
=> #<Proc:0x00338710@(irb):1>
irb(main):002:0> l(2)
4
=> nil
irb(main):003:0> {|x| puts x*2}(2)
SyntaxError: compile error
(irb):3: parse error
{|x| puts x*2}(2)
^
from (irb):3

By design, it's only intended to work for local variables for now AFAIK.

 

[Florian Gross]

(What happened to the S.find_all & idea, btw?)

We can do that:

class Symbol
def to_proc()
lambda { |other, *args| other.send(self, *args) }
end
end

irb(main):001:0> [1, 2, 3, 4].inject(&:+)
=> 10
irb(main):002:0> %w(foo bar qux).map(&:reverse)
=> ["oof", "rab", "xuq"]

 

[David A. Black]

Hi --

Aredridel ha scritto:

I agree, even if I think a little messing up it's ok, if the stuff that gets
broken is in remote corners. I don't expect ruby to be the same for ever.

I don't think anyone does. But that doesn't mean that every aspect of
its design has to have a countdown to removal or change, nor that new
things have to be added to it constantly. It *is* a good programming
language, you know

In any case, I'm not concerned about things breaking at 2.0. For me,
these "x without x" things are more a matter of too many shortcuts
and additions that don't feel entirely integral with the language.

For example, {|| } (lambda without lambda). For me, the question is
not whether it's possible to understand it (which it is). Rather,
the question is: if Ruby had been designed from the ground up with a
literal function constructor, would it have been {|| } ? If so, then
fine. If not, then {|| } would be an add-on that is not properly
integrated into the language.

And if the language really needs a literal function constructor, then
the best possible one should be chosen and everything else should be
rolled back until that constructor can be accomodated. And if too
much is rolled back -- if the language overall suffers -- then it
shouldn't be done.

I *think* that this is reasonably close to how Matz approaches things.
The lesson one learns repeatedly in all of this is: trust Matz -- he's
good at this!


David

 

[David A. Black]

Hi --

Hi,

In message "Re: Paul Graham recommends Ruby"

|Matz: can you clarify where this is going?

Nowhere. I'm just experimenting new syntax, such as

* a lambda without "lambda"
* call without "call"
* explicit block local variables
* etc.

They are fragile by nature. They might be removed in the future.

Thanks for the clarification


David

 

[David A. Black]

Hi --

Why? It seems natural to call a function with ().

I'm not sure about the naturalness of it -- I'm more thinking about
the fact that () isn't a method, whereas x(), where x is an object
reference (rather than a method identifier), looks like you're calling
the method () on x.

In other words, given this:

def a; end
b = lambda {}

a and b are not the same thing or kind of thing, but allowing a() and
b() (rather than a() and b.call) makes them appear the same. (I know
that they are both callable things, in a sense, but I'm examining it
at a more granular level.)

When I say I am confused by how this fits into Ruby, what I mean is
that it seems like a step toward some kind of method/lambda
unification, but not really a whole unification design. Matz's
explanation of these as experimental changes makes sense of that
perception.


David

 

[ES]

Hi --



I don't think anyone does. But that doesn't mean that every aspect of
its design has to have a countdown to removal or change, nor that new
things have to be added to it constantly. It *is* a good programming
language, you know

Agreed. I think it's healthy to throw ideas around, of course:
if someone thinks that a particular enhancement would work to
the advantage of the language then it should be by all means
voiced if only to see if others feel the same way. It could
even be seen as the responsibility of the community to provide
feedback to the language developers in the form of suggestions
as well as the obvious bug reports and such.

I suppose the important thing, though, is to not _demand_ things
(particularly since this service is provided free) and to not
be horribly insulted if one's suggestion is not viewed as essential
by others or even flat-out shot down (though courtesy could
certainly be reasonably expected from the duck hunters, too).

In any case, I'm not concerned about things breaking at 2.0. For me,
these "x without x" things are more a matter of too many shortcuts
and additions that don't feel entirely integral with the language.

For example, {|| } (lambda without lambda). For me, the question is
not whether it's possible to understand it (which it is). Rather,
the question is: if Ruby had been designed from the ground up with a
literal function constructor, would it have been {|| } ? If so, then
fine. If not, then {|| } would be an add-on that is not properly
integrated into the language.

Excellent point of view. Thanks!

And if the language really needs a literal function constructor, then
the best possible one should be chosen and everything else should be
rolled back until that constructor can be accomodated. And if too
much is rolled back -- if the language overall suffers -- then it
shouldn't be done.

For this particular issue I simply advocate formal first-order
functions of which class/instance methods are just, ah, special
lambda instances with certain scope and parameter bindings. I
certainly have no deep qualms with the current implementation
but, in my lay opinion, such a change would make things more
straightforward (to a user; it might be a language developers'
nightmare). Then again, I like Haskell.

I *think* that this is reasonably close to how Matz approaches things.
The lesson one learns repeatedly in all of this is: trust Matz -- he's
good at this!
Agreed.

David

E

 

[Navindra Umanee]

I'm not sure about the naturalness of it -- I'm more thinking about
the fact that () isn't a method, whereas x(), where x is an object
reference (rather than a method identifier), looks like you're calling
the method () on x.

It isn't a method in 1.9? Well, maybe it will be made a method or at
least a synonym/alias for call, although I guess that parsing-wise you
might have to find a compromise.

x() doesn't really look like a method any more than x[] does...

Cheers,
Navin.

 

[David A. Black]

Hi --

It isn't a method in 1.9?

No:

irb(main):006:0> {||}.methods.grep(/\(/)
=> []

Well, maybe it will be made a method or at least a synonym/alias for
call, although I guess that parsing-wise you might have to find a
compromise.

x() doesn't really look like a method any more than x[] does...

Actually there's a kind of double reasoning process involved here.
x[] is a method designed *not* to look like a method -- but it *is* a
method, can be redefined, etc. Therefore, () attached to a variable,
while also not looking like a method, looks like it should be one of
those things that don't look like methods but actually are. So it's
really within the framework of this kind of Ruby idiom that what I'm
saying applies.

That's why the overall naturalness or universality of () as a call-ish
thing isn't (for me()) the key thing. I don't want lambdas to know
about () unless () is a method. The best analogy is container
objects, which don't automatically know that they can be indexed with
[] but come to that point through the definition of the method #[].

(I offer the analogy for its explanatory power, not because it proves
that () "should" behave analogously -- though I think it should


David

 

[Malte Milatz]

Florian Frank:

Try the 1.9 cvs version:

irb(main):001:0> a = lambda { |x| x * 2 }
=> #<Proc:0xb7c6118c@(irb):1>
irb(main):002:0> a(1)
=> 2
irb(main):003:0> a 1
=> 2

I don't know whether I like that. If I understand correctly, it means that
a is an Object, whilst a() calls a.call. So the rule "parentheses are
optional" is no longer valid now.

To me, the following would make more sense (though it isn't Ruby anymore,
neither is it pragmatic):

a = defineb) do |x|
x*2
end

a.class --> Method
a.call(2) --> 4
a[2] --> 4

b(2) --> 4
b 2 --> 4

definec, a)
c(2) --> 4