context [was Re: Generic functions]
Fri, 21 Jul 1995 14:26:21 +0200
(This is not so much a reply to Frank's posting, rather an attempt to
clarify and to give the discussion a new direction. All this is nothing
new, just that I can't help but feel that some participants of the
discussion don't bear this in mind. Yet, most (hopefully) agree on most of
> In my view, location is based on namespace
> which is essentially a cluster of symbol objects.
In my view, location is based on objects, which are essentially a cluster
A slot associates a selector pattern (usually a name) with a value (usually
a reference to some other object). When the pattern is a name, a slot is
analogous to a binding which is analogous to a symbol. When all patterns
in an object are names, the object behaves like a namespace/ an
environment/ an obarray. You called it workspace, but i think it's a bad
idea to introduce yet another name for this concept. Let's say
environment. Or context, which I like best.
The word `context' is used for lots of different notions in computer
science: processor execution contexts (states), object execution contexts
(metaspaces), evaluation contexts (lexical environments), that ominous
`calling context' that Frank talked about (I think he meant a lexical
environment, after all) and probably some that i have forgotten.
This is sad, it has lead to much confusion not just on this list. (The
Sony folks working on Apertos don't even mention that they are talking
about processor states when mentioning contexts. You have to conclude that
from the context! ;-) In the German language, `Kontext' almost always means
`Zusammenhang' which means `association' and not `Umgebung', which is
`environment'. As far as I know, that is the mostusual everyday meaning of
`context' in english, too.
Modularization can be explained as dividing systems into smaller groups of
objects where each group of objects defines a context. The context/module
associates names with objects. Objects outside of the local context can
only be accessed by asking other contexts for them. These other contexts
are ordinary objects: if the context is not locally known, some locally
known context has to be asked for it.
Objects may be accessible from (reside in) more than one context, but there
is at most one object without a context. In particular, generic functions
belong to some context, but which one? I have the strong feeling that it
should be `close' to the objects it operates on.
Enough for now,