Attribution tuples (was Re: HLL Primitives)

[Brian T Rice]

On Fri, 7 Feb 2003, Armin Rigo wrote:

> Hello Brian,
>
> On Thu, Feb 06, 2003 at 11:14:12PM -0800, Brian T Rice wrote:
> > <key, object(s), value(s)>
> >
> > There's still an issue with distinguishing object and value
> > conglomerations as conglomerations rather than the objects that the
> > conglomerations *are*
>
> Just my two cents.  If I'm right, in Arrow, arrows themselves (which
> correspond to the <key, object, value> tuples) were first-class citizens, and
> were the only kind of objects available.  Here it seems that the tuple is just
> a specific kind of "tuple" object that may or may not be reified.

This is somewhat the case. The triples held when you coupled a graph with
an arrow that was in the graph, where the accessor to the graph was the
key.

In this case, the tuple is an abstract concept as well. It could be
implemented in various ways, and it doesn't have to be a 3-element
indexable (with integers) vector (an abuse of the mathematical term,
really, but it gets the idea across). Really it's just another object with
those 3 attributes. Any object conforming to that interface / type
specification qualifies.

> Thus the notion of conglomeration seems more fundamental in Arrow than here.
> I don't think there is a fundamental way to define or represent
> conglomerations here.  It could be any defined property that may or may not be
> reified as a set of tuples.  Am I making sense here?

No, it's just as fundamental here. All I would need are some collection
types and some reifiers for them, or wrappers or whatever: some way to
distinguish the behavior and intention of the collection. There would also
need to be graph types to capture the idea of a network of objects
connected by attributes. This is how I was using Arrow on Squeak, as a
meta-object protocol in this sense. It turns out that the graph types were
useful as a general library as well.

> The closest thing I see to the notion of "set of arrows" is given by a key.
> For example, a function given by "key" may be conceptually identified with the
> set of all <object, value> such that <key, object, value>.  Is it more
> fundamental than, say, the set of attributes of a given object (i.e. the set
> of all <key, value> such that <key, object, value>) ?

Yep, it's the key. As to which is more fundamental, I'd rather say
neither. Anything in Tunes should be replacable by something that
satisfies the same equations, so there's no real notion of fundamentality
except perhaps the equations themselves. (Although I suppose we might toy
with the equations, too, some day.)

The term "Quotienting" comes to mind, from Fare's HLL documentation, but
there's another set of issues that aren't layed out in enough detail yet.

-- 
Brian T. Rice
LOGOS Research and Development
mailto:water@tunes.org
http://tunes.org/~water/