Recently, I believe we decided that {} should, as a special case, be
an empty hash rather than a do-nothing code, because that's more
common.
However, what do we do about:
while $x-- && some_condition($x) {}
Here, while is being passed a hash, not a do-nothing code. Should we
force people t
On Wed, Dec 21, 2005 at 10:25:09AM -0800, Randal L. Schwartz wrote:
> > "Uri" == Uri Guttman <[EMAIL PROTECTED]> writes:
>
> Uri> i will let damian handle this one (if he sees it). but an idea would be
> Uri> to allow some form ofkey extraction via a closure with lazy evaluation
> Uri> of the
> "RLS" == Randal L Schwartz writes:
> "Uri" == Uri Guttman <[EMAIL PROTECTED]> writes:
Uri> i will let damian handle this one (if he sees it). but an idea would be
Uri> to allow some form ofkey extraction via a closure with lazy evaluation
Uri> of the secondary (and slower) key.
> "Uri" == Uri Guttman <[EMAIL PROTECTED]> writes:
Uri> i will let damian handle this one (if he sees it). but an idea would be
Uri> to allow some form ofkey extraction via a closure with lazy evaluation
Uri> of the secondary (and slower) key.
I still don't see that. I understand about the l
> "RLS" == Randal L Schwartz writes:
> "Uri" == Uri Guttman <[EMAIL PROTECTED]> writes:
Uri> sorting in p6 is not at all like in p5. instead of coding up an explicit
Uri> comparison code block and duplicating all the key access code (for $a
Uri> and $b), you will specify how to extr
> "Uri" == Uri Guttman <[EMAIL PROTECTED]> writes:
Uri> sorting in p6 is not at all like in p5. instead of coding up an explicit
Uri> comparison code block and duplicating all the key access code (for $a
Uri> and $b), you will specify how to extract/generate each key for a given
Uri> record. t
