----- 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
