concerns about Proc,lambda,block

Hi --

Dave's post about the block/proc/Proc section in the Pickaxe got me
thinking further about this whole area.

I think Dave's explanation is about as good as one can give -- and
that's what worries me.  In particular, the fact that Ruby is now
doing something that requires the concept of "contexts" to explain
strikes me as an indication of a possible problem.  

We've now got, essentially, Proc-in-an-iterator-context and Proc-in-
a-closure-context, as well as blocks (not Blocks), which are a
language construct but not an object.  I know Matz tried and rejected
the possibility of having two classes:

  Proc  -> method-like arg semantics
  Block -> iterator-like arg semantics

and building everything else up from that.  I admit I never understood
why that was rejected.  It seems to involve fewer twists than having
Proc objects choose their semantics based on their context.  

I could also imagine thinking of "closure" as the most basic,
fundamental description, covering any callable piece of code that
carried its creation environment with it.  Code blocks and Procs would
then all be closures (or Closures?).

I'm also wondering about the warnings for non-matching arglists for
block semantics.  If arity isn't strict, why give a warning?
Shouldn't it just either be allowed or not allowed?

Also, Dave's (correct, I believe) use of the phrase "for historical
reasons" troubled me....  With 2.0, big changes are allowed.
Hopefully historical reasons alone won't be sufficient -- ?

Anyway... I've really tried to look at this as carefully as I can, and
I still find it hard to reconcile myself to these aspects of it.
Comments and further thoughts very welcome.


David

-- 
David A. Black
[e-mail]