From: "David A. Black" Date: 2004-03-01T23:28:31+09:00 Subject: 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 dblack@wobblini.net