Feature #8168: Feature request: support for (single) statement lambda syntax/definition

[Gary Weaver]

Abstract: Proposal for single statement lambda support, either via a new type of stab '->>', such that '->> some value;' would be equivalent to '-> {some value;}', or by just supplying a stab operator '->' with a value instead of a block (which would be more intuitive).

Background: Often proc and lambda blocks are one statement long. Braces or do/end in this case are mostly unnecessary and result in less beautiful code

Pros: may reduce amount of syntax required, especially if can re-use same operator.

Cons: different stab operator may be confusing because of similarity to existing lambda operator. With either proposal, may cause additional overhead for interpreters.

[Gary Weaver]

Probably should have called it "expression lambda", not "statement lambda". Similarly "expression" not "value". Sorry, can't seem to edit.

[Gary Weaver]

So, redefining the proposal somewhat, '-> anexpression' or '->> anexpression' would be a shortcut for '-> {an_expression}'.

[Yukihiro Matsumoto]

• Status changed from Open to Feedback
• Assignee set to Yukihiro Matsumoto

=begin
What if the lambda takes the parameter e.g. (({->(x){x*x}}))?

Matz.
=end

[Usaku NAKAMURA]

• Tracker changed from Bug to Feature

[Gary Weaver]

@matz, You know best. :) !! I know that this request varies a bit when you consider that stab is a function call, but the goal is to de-uglify code that we are starting to have like:

some_method :some, :args, :here, -> {the block makes a single expression look ugly}

some_method :some, :args, :here, ->(x,y) {the block makes a single expression look ugly}

instead of the more beautiful expression lambda proposed as ->>. But, I think you are alluding to the issue that:

some_method :some, :args, :here, ->>(x,y) some expression

is bad, because with those parentheses, it looks like a function call to ->> which should take a block.

So, how about some other operator that could turn a single expression into a block?

Perhaps this could be ultracool, and look like:

someclassmethod :some, :arg, ->(x,y)> some expression

The obvious problem with that is that, though, may be that ">" would be taking on a special meaning in certain contexts, which would be difficult to read (and even more context sensitive to interpret?).

So, I guess that the best solution is possibly a syntactical symbol that indicates that the expression that follows it should be converted into a block during parsing.

I'm probably way off though. I wish that ->> would work, but perhaps it should be ->| or something. Thanks for taking time to consider this. It is just a nice to have, but Ruby is a beautiful language, and lambdas get so ugly, even with stabs.

[Gary Weaver]

Thinking about it a bit more, I guess it would have to be context sensitive. Just some character that is parsed when the block is being parsed that indicates that the following statement is a block. So maybe the best that could be done without a lot of overhead is whitespace between it, the method, and the block.

Then you just need to pick a good operator. I don't like the smiley here, but the world needs more smiles, so here it is for an example:

some_method :some, :args, :here, -> :) expression

Then you could also do:

def hello :) puts "hello world"

A single character that doesn't have many pixels like a colon would be best/most readable:

def hello : puts "hello world"

but colon is used by itself already in the ternary/conditional operator ?: (i.e., a ? b : c) so that might be confusing. Equals might look too much like an assignment:

def hello = puts "hello world"

I wish colon would work, because it would be a lot nicer-looking.

def a: b; def b: c; def c: d;

That just looks nice! :)

[Gary Weaver]

Oops except then they are symbols. Darn, too much to worry about...

[Charles Nutter]

As a feature that affects all Ruby implementations, this should probably move to CommonRuby: https://bugs.ruby-lang.org/projects/common-ruby

[Alexey Muranov]

I do not understand the argument about the code presumably looking ugly with curly braces (maybe if code looks ugly, it is better to read poetry? :)).

I do not think that

foo ->> Time.now

is more beautiful or clear than

foo lambda{ Time.now }

---

P.S. I think this proposal is somewhat related to #9076.

P.P.S. I also think that the notation ->(x){ bar(x) ... } was misplaced in the first place (should be more like something like { x |-> bar(x) ... }, if usual mathematical notation is implied), and the proposed use of ->> looks to me even more inappropriate, unless it is not expected to have anything to do with mathematical notation.

Edited.