From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-2.7 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 215E71F463 for ; Wed, 25 Dec 2019 19:34:28 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id CB80F120926; Thu, 26 Dec 2019 04:34:09 +0900 (JST) Received: from xtrwkhkc.outbound-mail.sendgrid.net (xtrwkhkc.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id 57694120905 for ; Thu, 26 Dec 2019 04:34:07 +0900 (JST) Received: by filterdrecv-p3las1-5bf99c48d-j57ff with SMTP id filterdrecv-p3las1-5bf99c48d-j57ff-19-5E03B9B0-28 2019-12-25 19:34:08.625436366 +0000 UTC m=+758904.264790636 Received: from herokuapp.com (unknown [3.83.106.33]) by ismtpd0079p1mdw1.sendgrid.net (SG) with ESMTP id OrcQqYOPSB-YZgV-VIW1bw for ; Wed, 25 Dec 2019 19:34:08.494 +0000 (UTC) Date: Wed, 25 Dec 2019 19:34:08 +0000 (UTC) From: zverok.offline@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 72133 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15973 X-Redmine-Issue-Author: alanwu X-Redmine-Issue-Assignee: matz X-Redmine-Sender: zverok X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?3be0g8093pjUjT94eiCA64csFDBI=2FmHQTWm54P5gda78oo7=2FbT7s58yZbCbAi7?= =?us-ascii?Q?4BFEQ4LJcSxXcCnHW62Z=2FOAP21lXnzBBJhQPQRi?= =?us-ascii?Q?l0Qh1Df38PEbiKQODiRQyxr=2FLq1Ml0p=2FxCnowLS?= =?us-ascii?Q?lAuSyc8G3XycTSzv0syuWp7=2FsFioK91s4BN3ksE?= =?us-ascii?Q?6CXvd1SemxDDDixP+mLjOi0UAfwrtyM31CBUwBb?= =?us-ascii?Q?vtjQtuCuKMPxnG9N8=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 96475 Subject: [ruby-core:96475] [Ruby master Feature#15973] Let Kernel#lambda always return a lambda X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" 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/