[Prev][Next][Index][Thread]

Re: lazy.dylan 0.1 -- add ML/Scheme-style lazy evaluation to Dylan

In article <slrn85llbq.bdn.neelk@brick.cswv.com>, neelk@alum.mit.edu wrote:

> I thought about it a little more, and then realized that the situation
> might even be a little worse than I imagined. If the generated code
> implements slot-initialized? as, say, a test for a NULL pointer, then
> any access into a potentially unitialized slot will require that test
> to guarantee safety.[*]

Right.  Including the use of "apply(values, s.vals)" in force().


> This check is subject to a stronger invariant than usual: namely, once
> an a slot is initialized it can never be unitiialized. So a dataflow
> analysis might be able to eliminate this check in a lot of cases.

Good point.  I'd be suprised if any current compiler actually manages to
take advantage of this though, in situations where it couldn't do the same
for a memoized? slot.

The current d2c, for example, still checks for a null "vals" slot in
"apply(values, s.vals)" even if I make the memoized? function inline :-(
so even the logic of...

   if not X
     set X
   use X

... is too tough for it to follow.  This may well be a bug, though, as it
*does* follow such logic for local bindings even though it doesn't for
slots of objects.


> So it makes sense to implement memoized? as a call to
> slot-initialized? -- then inlining and dataflow analysis would
> eliminate it where it's not needed automagically, since the compiler
> could plausibly know about it.

How about my other suggestion of using a distinguiished "not initialized" value?

define constant *not-memoized* = make(<sequence>);

define class <suspension> (<object>)
  slot expression :: <method>, required-init-keyword: expression:;
  slot vals :: <sequence>, init-value: *not-memoized*;
end class <suspension>;

define method memoized?(s :: <suspension>)
  s.vals ~== *not-memoized*;
end method memoized?;


In this case all slots are always initialized (which I like,
stylistically), which also means that no compiler-generated tests for
slot-initialized? are ever needed.

This perhaps (as per your point about slots not being able to be made
uninitialized after having previously been initialized) makes it very
slighly harder for a smart compiler to prove that the test in memoized?()
isn't required in some cases, but it certainly doesn't make it impossible.

-- Bruce

p.s. someone called Natarajan just told me he's the handsome one.
References: