From: Eric Mahurin Date: 2008-05-25T21:14:05+09:00 Subject: Re: lambda, ->, haskell, and so on ------=_Part_5359_28505737.1211717669297 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sun, May 25, 2008 at 6:46 AM, David A. Black wrote: > Hi -- > > On Sun, 25 May 2008, Phlip wrote: > > assert_yin_yang proc{ q += 0 }, 'it broke!', >>>> proc{ q == 42 } >>>> >>>> That sorta obviates my standard advertizing jingle - more assert bang >>>> for less coding buck! 'proc' ain't DRY there... >>>> >>> >>> I don't think I'd describe those two 'proc's as a case of repeating >>> yourself, since each of them is serving the minimal purpose that >>> 'proc' can serve. Or, to put it another way, proc { q == 42 } is in no >>> way a repetition of proc { q += 0 }. >>> >> >> You are correct that the most important aspect of the DRY rule is >> behavior, so to your trained Ruby eye the payload - q == 42 and q += 0 - are >> indeed distinct. In this way, 'proc' is structure, which is harder and less >> useful to DRY up. >> >> Yet if I'm trying to sweeten the syntactic sugar of my assertion, the >> 'proc' simply adds excess verbiage that adds nothing to readability. So the >> -> >> > > My view is that it isn't excess, any more than in this case: > > class A > ... > end > > class B > ... > end > > the second appearance of 'class' is excess. > > operator (or whatever it arrives as) will indeed be much safer than _{}! >> > > I'm still hoping it might arrive as "lambda" :-) > Take a look at the fully implemented 2 patches I posted yesterday. Here's what they do: "block w/ default args": allows block arguments to have defaults. I resolved | ambiguity by only allowing a for default values. This allows the normal "lambda" (not a keyword) to do the same thing as -> in a syntax we already know - block. "lambda w/ normal block syntax": automatically creates a lambda when { |...| ... } or do ... end are used in a . I require the |...| to be used for {} to disambiguate with a Hash. The are equivalent to preceding them "lambda". These two patches may be independently applied. They should cause any compatibility problems. ------=_Part_5359_28505737.1211717669297 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On Sun, May 25, 2008 at 6:46 AM, David A. Black <dblack@rubypal.com> wrote:

Hi --

On Sun, 25 May 2008, Phlip wrote:

assert_yin_yang proc{ q += 0 }, 'it broke!',
proc{ q == 42 }

That sorta obviates my standard advertizing jingle - more assert bang for less coding buck! 'proc' ain't DRY there...

I don't think I'd describe those two 'proc's as a case of repeating
yourself, since each of them is serving the minimal purpose that
'proc' can serve. Or, to put it another way, proc { q == 42 } is in no
way a repetition of proc { q += 0 }.

You are correct that the most important aspect of the DRY rule is behavior, so to your trained Ruby eye the payload - q == 42 and q += 0 - are indeed distinct. In this way, 'proc' is structure, which is harder and less useful to DRY up.

Yet if I'm trying to sweeten the syntactic sugar of my assertion, the 'proc' simply adds excess verbiage that adds nothing to readability. So the ->

My view is that it isn't excess, any more than in this case:

class A
...
end

class B
...
end

the second appearance of 'class' is excess.

operator (or whatever it arrives as) will indeed be much safer than _{}!

I'm still hoping it might arrive as "lambda" :-)

Take a look at the fully implemented 2 patches I posted yesterday. Here's what they do:

"block w/ default args": allows block arguments to have defaults. I resolved | ambiguity by only allowing a <primary> for default values. This allows the normal "lambda" (not a keyword) to do the same thing as -> in a syntax we already know - block.

"lambda w/ normal block syntax": automatically creates a lambda when { |...| ... } or do ... end are used in a <primary>. I require the |...| to be used for {} to disambiguate with a Hash. The are equivalent to preceding them "lambda".

These two patches may be independently applied. They should cause any compatibility problems.

------=_Part_5359_28505737.1211717669297--