From: Hugh Sasse Staff Elec Eng <hgs@...>
Date: 2004-03-02T00:04:36+09:00
Subject: Re: concerns about Proc,lambda,block

On Mon, 1 Mar 2004, David A. Black wrote:

> Hi --
        [...]
>   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 agree, I think this is something I'll have to keep looking up.
>
> 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?).

The only "reason" I can think of for not doing this is that creating
a Closure.new object rather than a block is "too" expensive.  I
don't know if that is true, or for what fuzzy values of truth, but
to hold all the scope info somewhere must cost somehing.

>
> 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?

I'd say it depends on the Warning level, as Ruby now has -w and -W.
I think having hints about possible problems with code is a good
thing [the machine is doing work to help the programmer], except in
so far as people then don't bother to test,  It sounds to me like
you would maybe accept this if it were at a high warning level.
Would you?  It's not for me to decide, of course,  but just while
exploring this...
>
> 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 -- ?

But this book documents 1.8, doesn't it?
>
> 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
>
>
>