Re: Record proposal

["R. Kent Dybvig" <dyb@cs.indiana.edu>]

> |   This would work, but I was operating under a different assumption.  A
> |   compiler may determine through flow analysis that a field of a specific
> |   record is no longer accessible, and I'd like for the system to be able
> |   to drop the field (or more likely, its contents) without worrying about
> |   access via the abstraction breaking mechanism.  We do exactly this for
> |   the contents of frames.  Flow analysis could also determine that, from
> |   a given point in a computation, a field is no longer mutable.
> |
> |   The mechanism I proposed also permits an inspector, for example, to
> |   determine fields that have been eliminated, which might be useful
> |   information to present to the user.

> I'm still unsure that I understand what you are saying.

> Is the field physically present in some instances but not others?

Yes, possibly.

> Or, alternatively, is the field meaningful in some instances but not
> others (because it hasn't been updated recently or at all after some
> point in the computation when the compiler thought it was no longer
> needed)?

Yes, possibly.

> If the field is available in some instances but not others, the system
> (i.e. the low-level part of the "abstraction-breaking" mechanism) must
> be able to tell for which instances it is available and for which it
> is not.  Since it can do that, it can also provide a default dummy
> value (or the actual current contents) for those instances for which
> it is not accessible.

This would be fine with me.  It provides less information to the consumer,
but is simpler and probably easier to implement.

Kent