On 11/7/07, Alain Frisch <alain@frisch.fr> wrote:
> The safe assumption is that a value
> identifier forces the value to remain live in all its syntactic scope
> (this is not a formal definition; for instance, a tail call terminates
> the scope of identifiers defined at the call site).

The situation is actually even worse than that, e.g.:

  let _, b = expr in
  ...

In the case above the first element of the tuple and the tuple itself
that "expr" evaluate to will remain live until "b" is accessed even
though they are not bound to names.  This is certainly very
unintuitive behavior.  One would at least expect that values that
never get bound and aren't reachable through other bound values aren't
considered live.

> I agree this might be surprising, but since I don't see the behavior
> changing for bytecode anyway, I don't think it is worth dealing with
> this case in native code (any program that relies on the improved
> behavior you ask for would have an unexpected behavior in bytecode).

At least what concerns us we are not overly concerned about optimal
behavior in byte code, because everybody that cares about performance
(also memory-wise) uses native code anyway.  I personally wouldn't
mind if byte code behaved differently wrt. GC-behavior.

> The proper solution might be to reflect in the syntactic scope your
> desire to see some value reclaimed:

True, but this quickly becomes cumbersome, and the user may easily
forget to do it in all places.  Space leaks are generally extremely
hard to spot.

It seems like an easy thing to do to implement the intuitive notion
that a bound variable is considered live in an expression if it occurs
freely in this expression.  This is still not perfect, because
liveness analysis is generally undecidable.  But it surely comes close
to the heuristics that humans probably use to reason about liveness in
their code and would thus not violate their expectations.

Regards,
Markus

-- 
Markus Mottl        http://www.ocaml.info        markus.mottl@gmail.com