[#38647] [Ruby 1.9 - Bug #5130][Open] Thread.pass sticks on OpenBSD — Yui NARUSE <naruse@...>

16 messages 2011/08/01

[#38653] [Ruby 1.9 - Bug #5135][Open] Ruby 1.9.3-preview1 tests fails in Fedora Rawhide — Vit Ondruch <v.ondruch@...>

31 messages 2011/08/01

[#38666] [Ruby 1.9 - Bug #5138][Open] Add nonblocking IO that does not use exceptions for EOF and EWOULDBLOCK — Yehuda Katz <wycats@...>

61 messages 2011/08/01
[#38667] Re: [Ruby 1.9 - Bug #5138][Open] Add nonblocking IO that does not use exceptions for EOF and EWOULDBLOCK — Aaron Patterson <aaron@...> 2011/08/01

On Tue, Aug 02, 2011 at 07:35:15AM +0900, Yehuda Katz wrote:

[#38669] Re: [Ruby 1.9 - Bug #5138][Open] Add nonblocking IO that does not use exceptions for EOF and EWOULDBLOCK — Urabe Shyouhei <shyouhei@...> 2011/08/01

(08/02/2011 07:46 AM), Aaron Patterson wrote:

[#38671] Re: [Ruby 1.9 - Bug #5138][Open] Add nonblocking IO that does not use exceptions for EOF and EWOULDBLOCK — Eric Wong <normalperson@...> 2011/08/01

Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:

[#38695] [Ruby 1.9 - Bug #5144][Open] Remove GPL file from repository — Vit Ondruch <v.ondruch@...>

17 messages 2011/08/02

[#38706] [Ruby 1.9 - Bug #5147][Open] mkmf should not require static library when ruby is built with --enable-shared — Vit Ondruch <v.ondruch@...>

9 messages 2011/08/02

[#38894] Why Ruby has versioned paths? — V咜 Ondruch <v.ondruch@...>

Hello, could somebody please elaborate about reasons why Ruby uses versioned

9 messages 2011/08/10

[#38972] [Ruby 1.9 - Bug #5193][Open] ruby_thread_data_type linker errors fixed with RUBY_EXTERN — Charlie Savage <cfis@...>

28 messages 2011/08/16

[#38980] :symbol.is_a?(String) — Magnus Holm <judofyr@...>

http://viewsourcecode.org/why/redhanded/inspect/SymbolIs_aString.html

8 messages 2011/08/16

[#39025] [Ruby 1.9 - Feature #5206][Open] ruby -K should warn — Eric Hodel <drbrain@...7.net>

14 messages 2011/08/19

[#39062] Releasing r33028 as Ruby 1.9.3 RC1 — Yugui <yugui@...>

Hi,

17 messages 2011/08/23

[#39093] [Ruby 1.9 - Bug #5227][Open] Float#round fails on corner cases — Marc-Andre Lafortune <ruby-core@...>

14 messages 2011/08/24
[#39115] [Ruby 1.9 - Bug #5227][Assigned] Float#round fails on corner cases — Yui NARUSE <naruse@...> 2011/08/26

[#39126] Re: [Ruby 1.9 - Bug #5227][Assigned] Float#round fails on corner cases — Marc-Andre Lafortune <ruby-core-mailing-list@...> 2011/08/26

Hi

[#39120] [Ruby 1.9 - Bug #5233][Open] OpenSSL::SSL::SSLSocket has problems with encodings other than "ascii" — Niklas Baumstark <niklas.baumstark@...>

9 messages 2011/08/26

[#39142] [Ruby 1.9 - Bug #5239][Open] bootstraptest/runner.rb: assert_normal_exit logic broken on Debian/GNU kFreeBSD — Lucas Nussbaum <lucas@...>

11 messages 2011/08/27

[#39162] [Ruby 1.9 - Bug #5244][Open] Continuation causes Bus Error on Debian sparc — Lucas Nussbaum <lucas@...>

29 messages 2011/08/28

[ruby-core:38954] [Ruby 1.9 - Feature #4102] Proposal for 'let'. A new approach using block-defaults in 1.9

From: Tom Wardrop <tom@...>
Date: 2011-08-15 01:48:58 UTC
List: ruby-core #38954
Issue #4102 has been updated by Tom Wardrop.


Thanks for the tips Magnus, they're very handy. I forget that begin ... end can be used just about anywhere to encapsulate multiple expressions that lead to a single result. The #tap method I simply had no idea about.

Cheers
----------------------------------------
Feature #4102: Proposal for 'let'. A new approach using block-defaults in 1.9
http://redmine.ruby-lang.org/issues/4102

Author: john mair
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 


=begin
 This is a very simple function, it would be implemented as follows:
 
     module Kernel
       private
       def let() yield end
     end
 
 First of all, do not dismiss this functionality out of hand because of 
 its simplicity.
 
 Even though it is just a 'yield', when it is combined with Ruby 1.9's 
 block defaults and new block-variable scoping rules it is actually quite 
 powerful and it behaves exactly like a let* in lisp.
 
 Some advantages of this functionality are:
 (1) Gives you precise control over the scope of your variables.
 
 I note that after the publication of "Metaprogramming in Ruby" by Paolo 
 Perrotta the following idiom has started to appear:
 
     proc do
       ..my code..
     end.call
 
 It is used exactly as the proposed 'let' would be used, but is 
 syntactically much uglier.
 
 Yes, i know an alternative is to just make shorter and smaller methods. 
 But is the ability to control and restrict scope ever a bad thing?
 
 (2) Testing and teaching about blocks.
 
 As the proposed 'let' simply yields to a block it can be used to 
 illustrate block behaviour and block concepts to a new Ruby programmer. 
 It also may be useful to an experienced programmer when trying out new 
 ideas.
 
 Here are some example uses of the proposed 'let':
 
 Example 1: Carve out a temporary scope, make 'x' local to that scope
 
     x = :outer
     let { |x| x = :inner } #=> :inner
     x #=> :outer
 
 Example 2: Here we use Ruby 1.9's block-defaults to make 'y' block-local 
 and give it a value:
 
     let { |y=10| y } #=> 10
 
 Example 3: Make 'x' and 'y' block-local and have 'y' value depend on 'x' 
 (equivalent to let* in lisp)
 
     let { |x=10, y=(2*x)| [x, y] } #=> [10, 20]
 
 In summary, I think this proposal should succeed for the following 
 reasons:
 (1) It is an exceptionally simple implementation.
 (2) More control over scope is never a bad thing.
 (3) I have seen people re-implementing this functionality themselves 
 using: proc { ..code.. }.call
 (4) It is very useful for teaching and testing block behaviour.
 
 Thanks,
 
 John
=end



-- 
http://redmine.ruby-lang.org

In This Thread

Prev Next