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=-3.0 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_PASS shortcircuit=no autolearn=ham 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 023AB211B4 for ; Tue, 8 Jan 2019 14:48:00 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id CB2E7118ECB; Tue, 8 Jan 2019 23:47:56 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id 41E54118EC2 for ; Tue, 8 Jan 2019 23:47:54 +0900 (JST) Received: by filter0096p3las1.sendgrid.net with SMTP id filter0096p3las1-4776-5C34B816-4C 2019-01-08 14:47:50.991728342 +0000 UTC m=+51396.389734632 Received: from herokuapp.com (ec2-54-82-77-37.compute-1.amazonaws.com [54.82.77.37]) by ismtpd0021p1iad1.sendgrid.net (SG) with ESMTP id _iwDLkr4Qfqr_TajESqMNA Tue, 08 Jan 2019 14:47:50.693 +0000 (UTC) Date: Tue, 08 Jan 2019 14:47:51 +0000 (UTC) From: manga.osyo@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 66360 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15483 X-Redmine-Issue-Author: aycabta X-Redmine-Sender: osyo 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: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS4QxtyBzc7+TPMlxzcNknnIGXq5FGQq9s+C7a vHC20qI5c8f9lssGcqViYdonw9nfDoWPpdElE8ZjFmCc/finqQaOEFHW0lfeceLTX0q4l2J+GUhB84 ZFpf5EeeBYvxGW2+XuIUCt6fzi7qN5Y306MOh6yCDj6UM0MyZ8+QZIuRDA== X-ML-Name: ruby-core X-Mail-Count: 90930 Subject: [ruby-core:90930] [Ruby trunk Feature#15483] Proc or Method combination with Symbol 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 #15483 has been updated by osyo (manga osyo). I am thinking like this. NOTE: Here we define it as follows. * functional object * defined `#call` (and `#<<` `#>>`) object * e.g. `Proc` `Method` * blockable object * defined `#to_proc` object * e.g. `Symbol` `Hash` ## Current * `Proc#<<` and `Proc#>>` arguments is functional object * call `#call`. * `Proc#<<` and `Proc#>>` is not call `#to_proc` * `Proc#<<` and `Proc#>>` is not accept block argument ## Composite function in Ruby * Composite function is functional object and functional object * `functional object >> functional object # => OK * `functional object >> other object` # => NG * `other object >> functional object` # => NG ## `Symbol` is functional object * `Symbol` is blockable object * `Symbol` is not functional object * Handling `Symbol` with compositing functions is incorrect * What about other blockable objects? * e.g. `Hash` * `Hash` is functional object? ## `Proc#<<` is call `#to_proc` ? * It should be explicitly converted to `Proc` (functional object) with` # to_proc` * `proc << :hoge` => NG: `:hoge` is not `Proc` * `proc << :hoge.to_proc` => OK : Explicitly convert `:hoge` to `Proc` * Same as not handling `"42"` as a `Integer` * `1 + "42"` => NG : `"42"` is not `Integer` * `1 + "42".to_i` => OK : Explicitly convert `"42"` to `Proc` ## Proposal1 : `Symbol` to functional object * define `Symbol#>>` `Symbol#<<` `Symbol#call` * What about other blockable objects? * `Hash` is functional object? * Is it really necessary for `Symbol` ? * Is `Symbol` really a "functinal object" ? ```ruby # Symbol to functional object class Symbol def call(*args, &block) to_proc.call(*args, &block) end def <<(other) to_proc << other end def >>(other) to_proc >> other end end p %w{72 101 108 108 111}.map(&(:to_i >> :chr)) # => ["H", "e", "l", "l", "o"] ``` ## Proposal2 : `Symbol` to functional object * `Proc#<<(other)` to `Proc#<<(other, &block)` * Prioritize `other` ? ```ruby class Proc prepend Module.new { def <<(other = nil, &block) # other or block? super(other || block) end def >>(other = nil, &block) # other or block? super(other || block) end } end # :to_i convert to Proc # must be `.>>` p %w{72 101 108 108 111}.map(&(:to_i.to_proc.>> &:chr)) # => ["H", "e", "l", "l", "o"] ``` ## Proposal3 : Define syntax sugar for `#to_proc` * For example, define `#to_proc` to `@~`. * or other Unary operator * `@+` `@-` `@!` `&` ? * Do not change current specifications * I think this is good ```ruby # Add ~@ class Object # ~ is to_proc # ~ or other unary operator? def ~@ to_proc end end # Use Symbol#to_proc p %w{72 101 108 108 111}.map(&(:to_i.to_proc >> :chr.to_proc)) # alias ~ is to_proc p %w{72 101 108 108 111}.map(&~:to_i >> ~:chr) ``` Thank you :) [Japanese](https://gist.github.com/osyo-manga/1725a4a670aac54452eca92269a3822b) ---------------------------------------- Feature #15483: Proc or Method combination with Symbol https://bugs.ruby-lang.org/issues/15483#change-76128 * Author: aycabta (aycabta .) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- In [Feature #6284], Matz said > We need more discussion if we would add combination methods to the Symbol class. Right, let's get started to discuss. For your information, recent a few months I'm discussing this with @osyo . ## This is a discussion of "design" I understand that all features of this issue have both merits and demerits, but I guess that language design is most important. All features of this issue related to each other. ## Abstract At present, you can use `Proc#>>` or `Proc#<<` with `Symbol#to_proc`. ```ruby %w{72 101 108 108 111}.map(&(:to_i.to_proc >> :chr.to_proc)) # => ["H", "e", "l", "l", "o"] ``` This is convenient but methods that take block can take a proc with `&` syntax sugar instead of `#to_proc` by right, like `[1, 2, 3].map(&:to_s)`. So `Symbol#to_proc` looks like too long for `Proc#>>` or `Proc#<<`. Therefore, you need new syntax sugar. ## Receiver ### `Symbol#>>` and `Symbol#<<` `Symbol#>>` and `Symbol#<<` will be considered, but this means that `Symbol` is treated as `Proc` partially. The `[1, 2, 3].map(&:to_s)` treats `Symbol` as `Proc` partially too, but it's with pre-positioned `&`. ```ruby %w{72 101 108 108 111}.map(&(:to_i >> :chr.to_proc)) # => ["H", "e", "l", "l", "o"] ``` I can't come up with other ideas for the `Symbol` receiver. ### New `&:symbol_name` syntax sugar for `:symbol_name.to_proc` ```ruby %w{72 101 108 108 111}.map(&(&:to_i >> :chr.to_proc))) # => ["H", "e", "l", "l", "o"] ``` ## Argument ### Calls `#to_proc` by `Proc#>>` or `Proc#<<` internally as a duck typing ```ruby %w{72 101 108 108 111}.map(&(:to_i.to_proc >> :chr)) # => ["H", "e", "l", "l", "o"] ``` In this case, `Proc#>>`(`:to_i.to_proc >>`) calls `Symbol#to_proc`(for `:chr`) inside. This is useful to use with `Hash#to_proc`: ```ruby h = { Alice: 30, Bob: 60, Cris: 90 } %w{Alice Bob Cris}.map(&(:to_sym.to_proc >> h)) # => [30, 60, 90] ``` ### `Proc#>>` and `Proc#<<` take block as an argument ```ruby %w{72 101 108 108 111}.map(&(:to_i.to_proc >> &:chr)) ``` ## Combination of receiver and argument `Symbol#>>` and calling `#to_proc` internally: ```ruby %w{72 101 108 108 111}.map(&(:to_i >> :chr)) # => ["H", "e", "l", "l", "o"] ``` `&:symbol_name` syntax sugar for `:symbol_name.to_proc` and `Symbol#>>` and taking block: ```ruby %w{72 101 108 108 111}.map(&(&:to_i >> &:chr)) # => ["H", "e", "l", "l", "o"] ``` -- https://bugs.ruby-lang.org/