[#2529] concerns about Proc,lambda,block — "David A. Black" <dblack@...>

Hi --

39 messages 2004/03/01
[#2531] Re: concerns about Proc,lambda,block — ts <decoux@...> 2004/03/01

>>>>> "D" == David A Black <dblack@wobblini.net> writes:

[#2533] Re: concerns about Proc,lambda,block — "David A. Black" <dblack@...> 2004/03/01

Hi --

[#2537] Re: concerns about Proc,lambda,block — matz@... (Yukihiro Matsumoto) 2004/03/01

Hi,

[#2542] Re: concerns about Proc,lambda,block — Mathieu Bouchard <matju@...> 2004/03/02

[#2545] Re: concerns about Proc,lambda,block — matz@... (Yukihiro Matsumoto) 2004/03/02

Hi,

[#2550] Re: concerns about Proc,lambda,block — Mauricio Fern疣dez <batsman.geo@...> 2004/03/03

On Wed, Mar 03, 2004 at 07:51:10AM +0900, Yukihiro Matsumoto wrote:

[#2703] Proposed patch to add SSL support to net/pop.rb — Daniel Hobe <daniel@...>

This patch adds support to Net::POP for doing POP over SSL. Modeled on how

19 messages 2004/03/27
[#2704] Re: Proposed patch to add SSL support to net/pop.rb — Daniel Hobe <daniel@...> 2004/03/27

This is v2 of the patch. Cleaned up a bit and added some more docs.

[#2707] Re: Proposed patch to add SSL support to net/pop.rb — Daniel Hobe <daniel@...> 2004/03/28

v3 of the patch:

[#2721] Re: Proposed patch to add SSL support to net/pop.rb — Minero Aoki <aamine@...> 2004/03/30

Hi,

Re: concerns about Proc,lambda,block

From: Hugh Sasse Staff Elec Eng <hgs@...>
Date: 2004-03-01 15:04:36 UTC
List: ruby-core #2530
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
>
>
>


In This Thread