[ruby-core:96490] Re: [Ruby master Feature#15973] Let Kernel#lambda always return a lambda

[atdot <ko1@atdot.net>]

Ok, make a new ticket about define_method. How about lambda?

Koichi

> 2019/12/26 4:34、zverok.offline@gmail.comのメール:
> 
> Issue #15973 has been updated by zverok (Victor Shepelev).
> 
> 
> Ugh, let me be a bit philosophical here (how many times I promised myself to not engage in discussions about Ruby's "spirit"? I've lost count.)
> 
> I understand the point you are speaking from (language implementer's background, who constantly fights with "dangerously illogical" parts), but for me, one of the key points of Ruby's attractiveness is how far it goes to reduce boilerplate in a logical and humane way. There is a non-neglectible gap between "human" consistency and "computer" (formal) consistency. 
> 
> I am writing in Ruby for >15 years now (and teaching it for >5 years, and blah-blah-blah). I've implemented and used metric shit-ton of DSLs. So, for me and my intuition is experience, it is just this way:
> ```ruby
> skip_if { |user| return 42 }
> ```
> ...is something that will behave "unexpectedly"? Yes. 
> Have I met a lot of cases when it was really written and shot somebody in the head? No.
> What if somebody really happens to meet with this case and is surprised? I believe they'll spend some time to wrap they head about it. That's a price we pay to have "complex language for writing simple code".
> 
> Now, when I see this:
> ```ruby
> def skip_if(&condition)
>  define_method(:skip?, &condition)
> end
> ```
> ...which "should" be "simply workarounded" to this:
> ```ruby
> def skip_if(&condition)
>  define_method(:skip?, -> *args { condition.call(*args) })
> end
> ```
> ...I see it as "your language implementation is really busy doing its important things. So it will not help you to write clean and obvious code. I (language implementation) see what you want to do (define methods implementation from a block in the variable), and I know how to fix it (block should be converted to lambda), but you (puny human) should do it with your own soft hands".
> 
> It _can and will_ harm the will to write simple helping DSLs (which, one may argue, "is a good thing" anyways?..)
> 
> Why, then, bother with "all this proc vs lambda nonsense" (as some may, and do, argue)? All in all, "you don't need this complexity at all", right? Because
> 
> ```ruby
> sources.zip(targets).map { |src, tgt| tgt.write(src) }
> ```
> ...can be "easily workarounded" as this:
> ```ruby
> sources.zip(targets).map(->(arguments) { arguments[1].write(arguments[0]) } }
> ```
> ...and everything suddenly becames more consistent and homogenous...
> 
> We can go this way really far, honestly :)
> 
> ----------------------------------------
> Feature #15973: Let Kernel#lambda always return a lambda
> https://bugs.ruby-lang.org/issues/15973#change-83402
> 
> * Author: alanwu (Alan Wu)
> * Status: Assigned
> * Priority: Normal
> * Assignee: matz (Yukihiro Matsumoto)
> * Target version: 2.8
> ----------------------------------------
> When Kernel#lambda receives a Proc that is not a lambda,
> it returns it without modification. l propose to change `Kernel#lambda`
> so it always returns a lambda.
> 
> Calling a method called lambda and having it do nothing in effect is
> not very intuitive.
> 
> https://github.com/ruby/ruby/pull/2262
> 
> Judging from marcandre's investigation here: https://bugs.ruby-lang.org/issues/15620#note-1,
> changing the behavior should not cause much breakage, if any.
> 
> 
> This also happens to fix [Bug #15620]
> 
> 
> 
> -- 
> https://bugs.ruby-lang.org/
> 
> Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>