From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: poffice@blade.nagaokaut.ac.jp Delivered-To: poffice@blade.nagaokaut.ac.jp Received: from kankan.nagaokaut.ac.jp (kankan.nagaokaut.ac.jp [133.44.2.24]) by blade.nagaokaut.ac.jp (Postfix) with ESMTP id 68D411F03A2 for ; Mon, 14 Sep 2009 18:58:14 +0900 (JST) Received: from funfun.nagaokaut.ac.jp (funfun.nagaokaut.ac.jp [133.44.2.201]) by kankan.nagaokaut.ac.jp (Postfix) with ESMTP id 44747EA57EA for ; Mon, 14 Sep 2009 18:58:16 +0900 (JST) Received: from localhost (localhost.nagaokaut.ac.jp [127.0.0.1]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id 11DDC2D4803 for ; Mon, 14 Sep 2009 18:58:17 +0900 (JST) X-Virus-Scanned: amavisd-new at funfun.nagaokaut.ac.jp Received: from funfun.nagaokaut.ac.jp ([127.0.0.1]) by localhost (funfun.nagaokaut.ac.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6eV0MGTNyBm for ; Mon, 14 Sep 2009 18:58:16 +0900 (JST) Received: from voscc.nagaokaut.ac.jp (voscc.nagaokaut.ac.jp [133.44.1.100]) by funfun.nagaokaut.ac.jp (Postfix) with ESMTP id CBA602D4801 for ; Mon, 14 Sep 2009 18:58:16 +0900 (JST) Received: from carbon.ruby-lang.org (carbon.ruby-lang.org [221.186.184.68]) by voscc.nagaokaut.ac.jp (Postfix) with ESMTP id B4F40952423 for ; Mon, 14 Sep 2009 18:58:13 +0900 (JST) Received: from beryllium.ruby-lang.org (beryllium.ruby-lang.org [127.0.0.1]) by carbon.ruby-lang.org (Postfix) with ESMTP id EF8313C224C9B; Mon, 14 Sep 2009 18:57:18 +0900 (JST) Received: from mail-yw0-f201.google.com (mail-yw0-f201.google.com [209.85.211.201]) by carbon.ruby-lang.org (Postfix) with ESMTP id 507CA3C22948A for ; Mon, 14 Sep 2009 18:57:11 +0900 (JST) Received: by ywh39 with SMTP id 39so4368524ywh.26 for ; Mon, 14 Sep 2009 02:57:09 -0700 (PDT) Received: by 10.90.143.16 with SMTP id q16mr3779014agd.26.1252922229849; Mon, 14 Sep 2009 02:57:09 -0700 (PDT) Delivered-To: ruby-core@ruby-lang.org Date: Mon, 14 Sep 2009 18:57:14 +0900 Posted: Mon, 14 Sep 2009 05:57:09 -0400 From: Cody Brocious Reply-To: ruby-core@ruby-lang.org Subject: [ruby-core:25571] Implicit block argument in Procs To: ruby-core@ruby-lang.org Message-Id: <4987c3660909140257g58c1f6e3keba9e312020a4a89@mail.gmail.com> X-ML-Name: ruby-core X-Mail-Count: 25571 X-MLServer: fml [fml 4.0.3 release (20011202/4.0.3)]; post only (only members can post) X-ML-Info: If you have a question, send e-mail with the body "help" (without quotes) to the address ruby-core-ctl@ruby-lang.org; help= X-Spam-Checker-Version: SpamAssassin 3.1.7-deb3 (2006-10-05) on carbon.ruby-lang.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=7.0 tests=ARIN,BAYES_20, CONTENT_TYPE_PRESENT autolearn=disabled version=3.1.7-deb3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=oGv5WdEDUiNDh5o7sc8bLHscEe6mSs4TN2kCjn95QOM=; b=ByXvURrloepHXTTQvVYmcvqEURu07dDhPyxqndC1VkbUG+MhR4pT2D1yVdPjAAXsj+ e3A6SbTNq85JlUX1VzkO1VHgU1UjGFpmlJFOjGtzWjxyCna7klU8w05vKC28jLzB8EnZ 3PGac2YKvqjQ0pnqBwpjrgc5KLpDdpgLOrMJ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=re7STSmhTnNTPqYY/Sv6Bp/2dvfzD1u8ZkrkJuuFLLVEkZ1xoEbRWnjvR9desBdKDW iIptcSWFDFEBpagT33tkhgf7ihTMuCeS3y8V+NnbFIZbCaV1H8F4zOcEv/v2DbAK5uDl CSFvCV4dRuF4zMKgp0CxGs4zLM5ILWa27MDq8= Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Precedence: bulk List-Id: ruby-core.ruby-lang.org List-Software: fml [fml 4.0.3 release (20011202/4.0.3)] List-Post: List-Owner: List-Help: List-Unsubscribe: I ran into some block behavior I thought was a bit odd. Calling a Proc (via .call or any other means) with a block causes the block to be silently dropped unless the Proc has an explicit block argument. This occurs even when taking a block as an explicit argument to another method and then calling that Proc. Below is a small bit of code which shows the issue in two ways: # Raw Proc proc = Proc.new { |&block| block.yield } proc.call { puts 'test' } # 'Block' Proc def set(&block) $block = block end set { yield } $block.call { puts 'test' } >From a quick glance at the source (specifically proc.c), the issue seems to be that in proc_call() there's the following line: if (BUILTIN_TYPE(iseq) == T_NODE || iseq->arg_block != -1) { Inside of that block the code that handles block passing. The iseq->arg_block != -1 check seems to prevent passing blocks unless they're explicitly named. Is this behavior intentional? If not, is there a limitation in rb_vm_invoke_proc() which makes passing an implicit block a problem? It seems that killing the arg_block check would solve the issue if there's no problem in rb_vm_invoke_proc(). Thanks, - Cody Brocious