Re: lambda, ->, haskell, and so on

Hi --

On Sun, 25 May 2008, Eric Mahurin wrote:

> On Sun, May 25, 2008 at 6:46 AM, David A. Black
<dblackrubypal.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.

I did see them, and I think they're very cool. I definitely
root for
the default argument behavior to be folded into lambda,
rather than
spun off into ->(){}. I admit I'm not a fan of the empty
||, though,
but I'm starting to think they'd be better than the arrow
syntax.


David

-- 
Rails training from David A. Black and Ruby Power and
Light:
   INTRO TO RAILS         June 9-12            Berlin
   ADVANCING WITH RAILS   June 16-19           Berlin
   INTRO TO RAILS         June 23-26           bond (Skills
Matter)
See http://www.rubypal.com for
details and updates!