----- Original Message ----- From: "Luke Palmer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, April 03, 2003 6:39 PM Subject: Re: Short-circuiting user-defined operators
> > 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. I prefer 1). When I posted the original thread I wanted to emulate the effect of $a && $b or ($a) ?? $b :: $c. The parameters in these might get evaluated zero or one times, but not more than once. Having a side effect happen more than once brings back painful memories of C-style macros. Joe Gottman