From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [94.130.110.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id ED4CC1F4C1 for ; Fri, 29 Nov 2024 23:53:21 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=IcOYLELC; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=heb7ED1E; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1732924399; bh=FrMXXO6/B+G3TDZYGa1B7C8iOgZ3nzAHbyWHkC2TwEg=; h=Date:References:To:Reply-To:Subject:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From:Cc:From; b=IcOYLELClE30A2coXlZy9UMxG7dMNP2xW7/STGiQ/931RIWOi0XtSnpnXX5kajir1 kEC/Nx0uHNGpUDzxAnEzeImvspcXWRzqHxyhRhov+aUYyMDZVdAAyojJUzTr9sxks/ LN5OMmk4FSP9pTtYfzrv6XF9b91TD+kIJt8ziGVA= Received: from nue.mailmanlists.eu (localhost [IPv6:::1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 0ADB144C65 for ; Fri, 29 Nov 2024 23:53:19 +0000 (UTC) Authentication-Results: nue.mailmanlists.eu; dkim=pass (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=heb7ED1E; dkim-atps=neutral Received: from s.wfbtzhsw.outbound-mail.sendgrid.net (s.wfbtzhsw.outbound-mail.sendgrid.net [159.183.224.105]) by nue.mailmanlists.eu (Postfix) with ESMTPS id 2F24744B36 for ; Fri, 29 Nov 2024 23:53:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ruby-lang.org; h=from:references:subject:mime-version:content-type: content-transfer-encoding:list-id:to:cc:content-type:from:subject:to; s=s1; bh=Y4VCS0voU8+IgDSitGEWnyv/9E5AGMO6sx1PpaMEghU=; b=heb7ED1E4rZ5pYiI3HCE81SVPljtwETnI8nPK1G3Zc5zxiAkzr0tuMRdkKBnlyS8OQ9t 3D9GTUjW22rdXW72kEkwUvA3J/WGzUjw0ji7/xA4snQElIQJBXIguzfx9DNQB71xl4B0DB Reb62uH9tbI9Gbzu1VCmkaEUIiWtWD9zZoM+YO2eFWkWxbOYF8abWgHct9u/7sR/bVPIX1 2L5d1uRkSl3m5r4d6fsnYyENdkY4WV0jsoVUd/gsg/Xc3SbWT0Fi+5LIXUfkwak6hxa8Kt e62w/f9FfRT2jW3ihag3nS4nsNTeW2DfMkyFpYYcEWArns06j3K6V9XnTbCCE7dw== Received: by recvd-5f54b5d587-cddpk with SMTP id recvd-5f54b5d587-cddpk-1-674A53E2-8 2024-11-29 23:53:06.632169643 +0000 UTC m=+1305014.133450127 Received: from herokuapp.com (unknown) by geopod-ismtpd-9 (SG) with ESMTP id UdYN20oETg-taRypYOe4fQ for ; Fri, 29 Nov 2024 23:53:06.546 +0000 (UTC) Date: Fri, 29 Nov 2024 23:53:06 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 20770 X-Redmine-Issue-Author: AlexandreMagro X-Redmine-Issue-Priority: Normal X-Redmine-Sender: AlexandreMagro 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-Redmine-MailingListIntegration-Message-Ids: 96740 X-SG-EID: =?us-ascii?Q?u001=2EpIF=2F17X3TAYiUJ7JM=2FkjfL3UcUjMXtwdvMQvfIr+dBsdQCbu7=2FyC8JO0y?= =?us-ascii?Q?XpK4kBnHSJ2ak3grQiHABQKRXGn67QaGY5Gvlwz?= =?us-ascii?Q?E1IK+8efZywRfwZH1sCvADkrvYscNpLvD58nxke?= =?us-ascii?Q?9ul1nr6wbXx9ARLjrQfoe947pF=2F+m0KRF0v3Ski?= =?us-ascii?Q?k=2FR+luSazZVlPwVpii7rqkxyUhIW5kpha6MKeeQ?= =?us-ascii?Q?0WIxprfyqKfqr0VITJkK60jSL5Ccprv9biiGfEu?= =?us-ascii?Q?RW=2FnJ9f4HmHuwJSnsVYqTKxVbw=3D=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: 7VXT2WDKC4INACPBMTZPKKJYTLN35H3Z X-Message-ID-Hash: 7VXT2WDKC4INACPBMTZPKKJYTLN35H3Z X-MailFrom: bounces+313651-b711-ruby-core=ml.ruby-lang.org@em5188.ruby-lang.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:120064] [Ruby master Feature#20770] A *new* pipe operator proposal List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "AlexandreMagro (Alexandre Magro) via ruby-core" Cc: "AlexandreMagro (Alexandre Magro)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #20770 has been updated by AlexandreMagro (Alexandre Magro). austin (Austin Ziegler) wrote in #note-53: > AlexandreMagro (Alexandre Magro) wrote in #note-52: > > austin (Austin Ziegler) wrote in #note-50: > > > It would *substantially* complicate parsing (one would only want to "assign" `_` if an expression *uses* it), and right now `_` is a valid variable name (if usually used for an unused parameter). > > > > Using the "last expression result" as a global behavior could introduce unnecessary performance overhead, as the interpreter would need to track and update it for every expression. > > Not necessarily. I don't know much about how the parser works to produce the AST, but if it is able to do a *small* bit of backtracking, it could detect the use of `_` (which would otherwise be an "unused variable") and mark the *previous* expression as requiring the last expression result. That would mean that the overhead would only exist when used. This sort of backtracking would be required with the use of `|>` in any case. > > > Furthermore, by explicitly using the pipe operator, the "last expression result" gains a clear meaning on its own, and no longer remains just an anonymous placeholder (`_`). This avoids the ambiguity that may arise in the code, which isn't an issue when writing expressions line by line in irb. > > I don't entirely agree. The ambiguity still exists because there is (more or less) an implicit block behaviour. If `_` already exists in the current scope, *both* the use of a pipe operator and the implicit "last expression result" would potentially shadow or overwrite the use of `_`. (It may be a silly idea to use a variable called `_`, but it is *legal* to do so right now.) Using the "last expression result" as a global behavior offers no real advantage over the pipe operator. The pipe operator provides a predictable and explicit structure: "Developer, the next expression depends on the result of this one." This clarity makes the code easier to read and follow. In contrast, treating the "last expression result" as a global behavior introduces the potential for confusing and poorly written code. It could lead to situations where, at first glance, a line of code appears self-contained, only to reveal midway through our mental evaluation that it depends on a prior expression. This undermines readability and makes debugging more challenging, especially in larger or collaborative codebases. The IRB has this behavior, but there we are debugging line by line. ---------------------------------------- Feature #20770: A *new* pipe operator proposal https://bugs.ruby-lang.org/issues/20770#change-110804 * Author: AlexandreMagro (Alexandre Magro) * Status: Open ---------------------------------------- Hello, This is my first contribution here. I have seen previous discussions around introducing a pipe operator, but it seems the community didn't reach a consensus. I would like to revisit this idea with a simpler approach, more of a syntactic sugar that aligns with how other languages implement the pipe operator, but without making significant changes to Ruby's syntax. Currently, we often write code like this: ```ruby value = half(square(add(value, 3))) ``` We can achieve the same result using the `then` method: ```ruby value = value.then { add(_1, 3) }.then { square(_1) }.then { half(_1) } ``` While `then` helps with readability, we can simplify it further using the proposed pipe operator: ```ruby value = add(value, 3) |> square(_1) |> half(_1) ``` Moreover, with the upcoming `it` feature in Ruby 3.4 (#18980), the code could look even cleaner: ```ruby value = add(value, 3) |> square(it) |> half(it) ``` This proposal uses the anonymous block argument `(_1)`, and with `it`, it simplifies the code without introducing complex syntax changes. It would allow us to achieve the same results as in other languages that support pipe operators, but in a way that feels natural to Ruby, using existing constructs like `then` underneath. I believe this operator would enhance code readability and maintainability, especially in cases where multiple operations are chained together. Thank you for considering this proposal! -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/