[proto-rcr] Blocks: default arguments and method signatures

I thought I'd post these ideas here, since last time I wrote up an RCR 
and then got told that the issue had already been addressed in plans for 
Ruby 2. Also, some ideas I'm pretty happy with, some are quite 
radical/provocative. Hopefully those latter bits are somewhat 
independent, which ones do you like? (if any ;)
So please let me know if I'm missing something, or this could be done 
better.

1) Default arguments for &block
Often a method performs some simple reasonably useful behaviour if no 
block is given, otherwise it lets the block do something more useful. 
For example:

def transform_values(array)
	out=[] unless block_given?
	array.each { |value|
		# calculations...
		if block_given?
			yield value,newvalue
		else
			out<< newvalue
		end
	}
	out
end

I propose &block could take a default argument, probably of the form
&block={|x| foo}, but I could live with &block=proc {|x| foo}.
block_given? would return *false* if the default value was used (I'm 
flexible on this bit).
The default block would be scoped *inside* the method.
That example would become:

def transform_values(array) &block={|val,newval| out<< newval}
	out=[] unless block_given?
	array.each { |value|
		#calculations...
		yield value,newvalue
	}
end

2) Taking anonymous block parameter, making it part of the signature
Two issues:
   	a) If block default values are adopted, then giving the block a
	     name might sometimes seem silly, as the name's never used.
	     See the above example, "block" is never referenced.
	b) No way to specify taking a block as part of method signature.
	     Descrptive signatures are good:
	     * See syntax in auto-docs/code without reading whole thing
	     * See syntax in auto-docs/code when there's no comments		
	     * Flag errors at start of method, and on every invocation.	

Proposal: allow "&" in place of "&block":
def foo &	(or maybe: def foo &!)
	As soon as the method is called, raises an error if no block is
	given (similar to wrong number of args)
def foo &?	(or maybe: def foo &)
	No change from current behaviour of def foo, but denotes that
	this method can take a block and might use it if given.
(MAYBE:)
def foo &block! or
def foo &!block	or
replace current meaning(!) of: def foo &block
	This method is required to take a block, not passing a block
	raises an error.
def foo &block or
def foo &block? or
def foo &?block, etc
	Current meaning of &block.

My preferred syntax in a throw-everything-away-for-Ruby2 scenario:
		Named block		Anonymous block
Disallowed	def foo			def foo
Optional	def foo &block?		def foo &?
Defaulted	def foo &block={}	def foo &={}
Compulsory	def foo &block		def foo &

My preferred syntax in a backwards-compatible scenario:
		Named block		Anonymous block
Disallowed	-			-
Optional	def foo &block		def foo &?
Defaulted	def foo &block={}	def foo &={}
Compulsory	def foo &block!		def foo &!

Thoughts?
Sam

Hi --





I can definitely see the point of the default assignment, but I
think you're changing too much here by putting it outside the
arglist.  &block is a special argument, I know, but it's still
part of the list.  

I also don't like the forward reference to a local variable here
(out).  When you get to this:


it really feels a bit convoluted.  


I think block.call(value,newvalue) would be clearer here, since yield
really means that the business is being done by switching control to a
block provided in association with the method call.  I understand that
you're sort of retro-fitting your default block to play that role, but
I still think it's better to save yield for the traditional yield
scenario.


You're not returning 'out'?  And if you are, are you sure you want
the return value to be nil if a block was given?

Just for completeness, here's a present-day version that returns the
original array if a block is given, and otherwise returns the
accumulated transformations:

  def transform_values(array,&block)
    res = if block then array else [] end
    block ||= lambda {|val,newval| res << newval }

    array.each do |value|
      newvalue = value * 10
      block.call(value, newvalue)
    end

    return res
  end

  # A couple of test runs:

  p transform_values([1,2,3])
  p transform_values([1,2,3]) {|x,y| puts "#{x} => #{y}" }

  # Output

  [10, 20, 30]
  1 => 10
  2 => 20
  3 => 30
  [1, 2, 3]


David

-- 
David A. Black
 XXXX@XXXXX.COM 

That was a typo :-#

Yes, as I posted above, I tested the equivalent code but made a mistake. 
I withdraw this part :)

Or the block could be anonymous, which might be clear enough...

Oops, I forgot. I really couldn't test this one!

That was the intention in this example. (Recently I've been using large 
data sets, one huge array is enough!)

Nice, I like the res trick...
For that matter:

def transform_values(array,&block)
    array.map{|value|
       newvalue=value*10
       block ? begin
         block[value,newvalue]; value
       end : newvalue
    }
end

Thanks,
Sam

Since most of the problems in here have been hashed over already by 
those more competent than me, I'll just mention one thing that caught 
my eye:





To me, that code should make a new variable, named 'block'. How about 
this:

   def transform_values(array) {|val,newval| (out||=[])<< newval}
     out=[] unless block_given?
     array.each { |value|
       #calculations...
       yield value,newvalue
     }
   end

(note that or-equaling 'out' solves the forward reference problem, at 
the cost of some visual cleanliness)

Basically, an unassigned block at the beginning of a method declaration 
would be taken as the yield block.

Another possibility would be to give the block it's own binding, as if 
it was defined in an intermediate method. That way, you wouldn't ever 
have to worry about namespace clashes.

cheers,
Mark