Attributes

[David E. Manifold]

I am replying to a message Fare wrote me on May 7.
Because it was so old, I feel justified to quote the whole thing.  I
apologize if this is annoying.
(Also since the archive isn't being updated)
> [Fare]
>> [dem]
>> What is an attribute?  I can't seem to figure out the difference between
>> this and a function.  You say the implementation may make the difference
>> meaningless; but I don't quite understand the theoretical difference.
>>
>An attribute can be conceptually thought of as a memoized function:
>you have a function that associates some abstract value to some objects,
>but want to remember that value permanently without having to recompute it.

The caching of a function result is a separate topic; and is an
implementation detail.  Caching of results can occur on any arbitrary
function; I don't understand how it applies to attributes.  Do you mean that
any cached value is called an attribute?  Do you mean that one example of
implementation of an attribute is a function with its value forcibly cached?

>* If the function is pure, then there is no semantical difference
> between an attribute and a function

The fact that you state this here implies that attributes are more widely
used in the system than I thought; I was under the impression that
attributes were a special case.  In any situation, an object has the same
semantics as a function if the function is pure.  For example, in C a
function that returns type int can be used anywhere an int can.  Similarly,
but to a greater extent in Tunes, you will be able to use functions and
objects interchangeably.

To confirm my understanding of purity, a function is pure if it only
performs actions necessary to its purpose.  For example if a function is to
calculate a result, it doesn't also create a persistent variable somewhere
that remains when the function exits.

>* If the attribute gets garbage collected,
> then all the individual memoized information gets garbage collected;
> if an object gets garbage collected, its attribute disappears, too.

Are you sure?  If I specify how to display my object, and I destroy the
particular instance of the object, what if I had a backup compressed in
another module and I wanted to retain the display settings in case I ever
looked at the object again?

>* If you want to be able to associate varying values to objects,
> then use a reference as the attribute;
> that's the ML way of making side-effects orthogonal to other computations.
Still, adding a reference makes the object impure; it no longer just
contains data relevant to its meaning.  The information is perhaps relevant
to this specific occurence of the object, but it should be stored separately.

>* You don't want people to read an attribute?
> Just don't export the attribute reader to anyone's scope.
>* The exact implementation of attributes is undefined;
> might be fields added to the object's representation;
> might be information nodes inserted in the structure;
> might be a centralized or decentralized association list or hash table;
> might be just anything you can imagine,
> as long as the overall abstract semantics is the same.
> the responsibility is left to implementers (with programmers' hints welcome).
>
>Let's take some usual examples:
>* You've got a structure that you'd want to pretty-print, display, or edit.
> Then, you're going to define for every "node" in the structure
> attributes that describe where and how it will be displayed
> (font, indentation, size, color, whatever).
>* the system has a concept of "user", built in some module.
> You want to add some accounting/logging information about users.
> No need to rewrite the module that define users.
> Just define a new attribute of users.
> Same goes with password systems, etc.
>* you want to type a program. Give each node a type attribute.
> [Note: programs are stored abstract structures, not ASCII]
I'm assuming also after you've typed it, that you would want to prove it
secure, and that once it is proven, you want the type to remain part of the
final object definition.  At this point the attribute becomes part of the
object, and no longer is known as an attribute.

>* you are not satisfied with the way the pretty printer manages
> parts of your program; you ask it to remember the layout,
> or particular layout tactic to use for such parts of the program.
>* you want to comment a program.
> Annotate its structure with comments in french, german, chinese, martian.
>* you want to translate a program.
> Annotate each node with all the meanings you could find about it,
> before you can understand it and synthetize a translation.

You seem to be speaking of Attributes as the same thing as Annotations.  Is
it true that you use the two terms synonymously in all cases?

Is an attribute a vital part of an object, for its purpose, or is it just
extraneous information that is useful elsewhere when talking about the object?
Are you getting the two mixed up?  Might you try to use an attribute for
either purpose?  The concepts, I believe, are incompatible and should remain
separated. 

OK, I guess what I am confused about is whether attributes go in the
instance of an object.  If you have a large number of instances, and you add
supplementary (commentary) information to a few of them, but not all,
clearly the information added should not go in as part of the definition of
that object, since that would add a field to every instance (And in many
instances, it would be blank, and therefure wasted).  However, supplementary
information should not, in my opinion, be stored in the object it is
supplementing.  Nor should a pointer to the supplement be present in the
object being described.  It should be stored separately, in the context of view.

My point is that I see the definition of Attributes as the second item on
the HLL Semantics.  This tells me that Attributes must be an important part
of the HLL.  However, from what I have been told about Attributes, they seem
like a part of the system that could be added in *after* the HLL was fully
founded; in other words, not a requisite part of the HLL, but just a feature
of the system.

Please help me understand Attributes, so I can know if they are a vital part
of the system or not.  It seems to me the functionality you describe as
belonging to Attributes could be implemented in the system within the
definitions of "Object" and "Context".

David E. Manifold
dem@pacificrim.net