Re: Record proposal

[Guillermo J. Rozas <gjr@martigny.ai.mit.edu>]

|   Date: Mon, 29 Apr 1996 16:32:32 -0500 (EST)
|   From: "R. Kent Dybvig" <dyb@cs.indiana.edu>
|   Cc: rrrs-authors@martigny.ai.mit.edu
|
|   > Thus, record-type-field-names (or whatever it is called) can just not
|   > provide that field name at all, since such fields are unobservable.
|   > Thus any field would be accessible, but not necessarily mutable.
|
|   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?

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

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.

Thus I'm not sure what declaring the field not to be available for an
instance really does.

|   I'm not sure I'd dismiss it as a matter of style, but okay.  I'm trying
|   to make it clear that programmers should use the accessors and mutators
|   generated by define-record if they want to manipulate specific fields,
|   i.e., that the ones obtained by way of record-descriptor are intended
|   for meta programming purposes only.

No disagreement here.