On Sunday, August 14, 2011 17:39:29 Brad Roberts wrote: > On Sunday, August 14, 2011 2:30:39 PM, Jonathan M Davis wrote: > > On Sunday, August 14, 2011 23:20:12 Timon Gehr wrote: > >> On 08/14/2011 10:36 PM, Jonathan M Davis wrote: > >>> On Sunday, August 14, 2011 22:25:36 Timon Gehr wrote: > >>>> On 08/14/2011 10:00 PM, Vladimir Panteleev wrote: > >>>>> On Sun, 14 Aug 2011 22:48:18 +0300, Timon > >>>>> Gehr<[email protected]> > > > > wrote: > >>>>>> requiring lazy before lazy arguments basically destroys the > >>>>>> reason > >>>>>> for > >>>>>> lazy being in the language: > >>>>>> > >>>>>> int foo(lazy 2*3); > >>>>>> > >>>>>> is not better than > >>>>>> > >>>>>> int foo({return 2*3}); > >>>>> > >>>>> What about requiring "lazy" only for non-pure delegates? > >>>> > >>>> Actually I would rather require lazy arguments to be pure, so that > >>>> they > >>>> can be guaranteed to be executed at most once. > >>> > >>> That still wouldn't be guaranteed, since pure function calls are > >>> only > >>> optimized out if they're strongly pure and in the same expression. > >>> You > >>> can't rely on calls to pure function > > s being optimized. > > >>> - Jonathan M Davis > >> > >> My point was, that if lazy arguments were required to be pure, such a > >> thing _could_ then be guaranteed independently from optimizations that > >> may or may not take place on general pure functions. > > > > Yes. In theory. It would depend on what Walter was willing to do with > > the > > language and the compiler though. At present, pure is purely an > > optimization and not use to affect semantics at all. > > The pure keyword doesn't _change_ semantics, but it very much affects > semantics, through restriction and the guarantees it provides. The > restrictions help enforce some very specific and broadly useful > behaviors. But you know this. > > > However, I'd actually argue that lazy delegates should be effectively > > treated as pure anyway. Conceptually, what you're doing is delaying the > > execution of the expression in case it isn't needed. I don't see any > > reason why the end result should be any different from passing a > > non-lazy a > > rgument. As such, the > > > lazy argument should only be called once regardless. It wouldn't > > surprise me at all if the implementation doesn't work that way, but I'd > > argue that it should regardless of purity. From the standpoint of the > > function, the lazy argument is just like any other argument in terms of > > its value, and IMHO it should be treated that way. > > That's not the way it behaves, or is defined to behave. Lazy > parameters are executed 0-N times, entirely based on the implementation > of the method itself. It _could_ be re-done to mean 0 or 1, but that's > still not always 1. If it was, might as well kill the lazy concept.
Oh, I know that it's not always 1, and I'm not suggesting that it always be 1. I'm suggesting that it always be 0 or 1, and that it not actually be called multiple times even if it's referenced multiple times. I don't see why there is any value in having it called multiple times. In concept at least, a non- lazy parameter is the same as a non-lazy except that it isn't evaluated unless it's used. And so I don't see why you'd want to be evaluating it multiple times except that it's probably easier to implement that way. - Jonathan M Davis
