--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> > Paul wrote:
> > > --- Austin Hastings <[EMAIL PROTECTED]> wrote:
> > >
> > >>Dave Whipp wrote:
> > >>
> > >>>Joe Gottman wrote:
> > >
> > >
> > > Getting deep -- sorry. :)
> > >
> > >
> > >>>>Alternatively, there might be a new parameter type that
> indicates
> > >>>>that the parameter is not evaluated immediately:
> > >>>>
> > >>>>sub infix:!! ($lsh, $rhs is deferred) {...}
> > >
> > >
> > > If the standard is pass-by-ref it wouldn't trip any side effects
> unless
> > > you did so in your code, right? So is this necessary?
> > >
> >
> > There are two reasonable semantics for deferred parameters:
> >
> > 1) lazy evaluation with caching, where the evaluation of the
> > actual expression in the call is deferred until the sub
> > actauly makes use of it and the result is then cached and
> > reused as necessary. Any side effects happen only once.
> >
> > 2) ALGOL style pass by name, where the actual expression from the
> > call is turned into a clouser called a thunk which is called
> > when ever the sub access the parameter. Note that the thunk
> > may need to be an lvalue clouser to handle is rw paramenters.
> > Side effects happen each time the thunk is called. Also changes
> > to the thunks environment can effect its value when called.
>
> I think (2) would be best. Because of:
>
> while $a < $b { ... }
>
> That wouldn't be possible with just evaluating it once. I like the
> interface better, too (for the writer of C<while>), but that's just
> me.
Since parms are defaulting to reference, could I just say:
sub foo($arg) { while $arg >= 0 { print $arg; } }
foo( \{ $i-- } );
or: foo \{ $i-- };
or: foo {$i--};
and get that behavior? Is that a good idea?
Regardless, consider:
$a || $b && $c
This translates to:
infix:||($a, infix:&&($b, $c))
so if I want to write infix:!! I could do:
infix:!!($left, &right is expression) is equiv(infix:||)
{
return unless predicate($left);
return $left << &right;
}
But this have the unfortunate side-effect of requiring that all use of
the !! operator take place after the declaration -- not the end of the
world except when you want to overload a "known" symbol and make a
"short-circuit bitwise or" operator that does something other than
bitwise-or, perhaps.
In which case, go code C++, or write a macro, or get your declaration
to the top of the pile.
But this WILL impact the code generator/optimizer. Perhaps P6 needs the
notion of sequence points...
>
> Luke
=Austin
