Term "Configuration"

[Brian T Rice]

On Wed, 23 Apr 2003, Mario Blazevic wrote:

> Brian T Rice wrote:
> >I do think that environments relate, although that's more of a /use/ or
> >/role/ that a configuration can fulfill rather than something essential.
> >You can say that the environment is part of the context (actually, this is
> >what most textbooks say), and then talk about how expressive the ways of
> >fiddling with the environment or requiring certain characteristics of the
> >environment can be, and this is what touches on configurations without
> >actually acknowledging that subject.

> Yup. I said that configuration is a more general thing than my
> environment. What I don't quite understand yet is how is a configuration
> applied to configure a program (or library, or a bunch of objects) and
> alter its behavior. Is the configuration actively modifying the program
> or is the program querying the configuration for parameters? In the
> latter case, does the program rely on some configuration being there to
> query?

I think you're reading too much into this. A configuration in the sense
I'm using it is a descriptive meta-object, like the type of some things in
the aggregate sense. Actually, that's one step of indirection from what I
mean, since the type of an aggregation is possible to express /if/ you can
express a configuration. I'm also not distinguishing between data and
programs, except that certain objects represent others in a computational
linguistic context. Active objects are what equate to programs for TUNES.

Perhaps if you defined "program" here, it would help. In an environment
which just consists of objects, I have a difficult time expressing what
exactly constitutes "the program". If you mean a single basic function
body, then the distinction between "the configuration actively modifying
the program" and "the program querying the configuration for parameters",
then you'd have to specify what role you mean for the configuration to
take. You could mean the configuration for the parameters (ie part of the
dispatch configuration), or the configuration of the relevant parts of the
environment; I can't determine which.

In the case that you mean a function / lambda body, the answer to the
first question is that the program queries for the parameters. Although,
in a philosophical sense, you can say that the answer is just a matter of
perspective, asking about the locus of activity; Fare would answer with
"the meta-level". :) The answer to the second question is that anything
that the function accesses is something it relies on. Anything it
*dispatches* on must be present / fulfilled for the call to occur on that
particular body. In either case, the implementation of whatever attributes
are accessed is entirely independent from its being required.

> >>Anyway, the point I'm trying to make is that the selection can be
> >>treated as a function call with multiple arguments, where arguments are
> >>attributes of the context environment, and the function is the evaluated
> >>term. The function can return another environment, and the caller can
> >>either take the whole environment or select one of its attributes as as
> >>the result of the call. An interesting consequence (to me anyway) of the
> >>system is that, if you simply use the result environment as the context
> >>of another selection/function call, you're threading the side-effects of
> >>the first function call into the second one. You don't need to know or
> >>care what these effects are, but you're free to either pass them on or
> >>select the pieces you need.

> >Well, the "selection" term slightly confuses me, but I regard it as
> >analogous to slot access in Self or Slate... any reference to a value in
> >the current environment is implicitly a call on the surrounding namespace
> >object (namespace being a /role/, not a /type/). And this kind of metaphor
> >over traditional environment situations seems to be what you are
> >describing, except for the "multiple arguments" part. Oh, but I see that
> >you're talking about terms again and not their denotations; from my
> >perspective there's some confusion here between context and environment
> >configuration.

> Self's slot access is indeed eqivalent to my definition of selection in
> the simplest case, when the selected object is just a slot label and the
> context object contains the slot so labeled. But selection is defined
> over any two terms. Oh, when I say "terms" I mean both "a well-formed
> piece of syntax" and "syntax tree resulting from it". Also, every term
> has definite semantics and a static type, but its execution, or (better
> to say) its normal form, will depend on the context it's evaluated in.

I get a rough intuitive picture, but your thought pattern is confused. The
"context argument" to you is the argument of the selection. The "selected
object" is the /name/ of the slot/attribute, according to you, instead of
the value returned from the slot/attribute. After that, you start talking
about apparently nonsensical ideas about syntax. Now you say a selection
is between two terms, where you define terms to be from two separate
domains, and then you say they have "static type", but only variables can
have static type, not values (values just have types). And then you say
that evaluation depends on context, which is to say that late-binding
seems to be in effect.

> Maybe I should expand on the Self and Slate analogy you offered. The
> driving idea of object-based languages is that "everything is an
> object". Let's take that literally. If *everything* is to be an object,
> then a message-send must an object too. And what about method bodies? A
> sequence of method sends (i.e. objects) should also be an object. Same
> for closure.

The design decision for your method body sounds confused even for a
thought experiment. Bodies are not just sequences of message-sends (you
send messages, not methods). If you look at Slate's syntax definition of
MethodNodes at
http://tunes.org/cgi-bin/viewcvs.cgi/slate/src/compiler/syntax.slate?rev=1.9&cvsroot=Slate&content-type=text/vnd.viewcvs-markup

you will see something appropriate, and representative.

> Ok, so what kinds of objects are they? What's their semantics? What are
> their slots and their inheritance? There are different possible answers,
> but the most useful arrangement I've found is that slots of a message
> object are the message arguments, and that it inherits the object it's
> passed to. I call this kind of object a selection. A sequence-of-objects
> has the slots of both its components, but the slots of the right hand
> side object take precedence over the left one. And I don't have any
> closures. Methods don't really have explicit arguments, because message
> arguments are slots and can be accessed the same way all slots are
> accessed.

The statement that "slots of a message object are the message arguments"
makes sense for your hypothetical design and somewhat relates to Self or
Slate, assuming by "message object" that you mean the analogue of the
Smalltalk family's MessageSend type. Everything else is very confused
speculation, it seems. The statement about "a sequence-of-objects" doesn't
relate to any concept that I can perceive. Not having closures makes no
sense when you speak of a lambda calculus background. "Methods don't
really have explicit arguments" is a non-sequitur. Even after all of that,
this definition of selection is not a generalization of your previous
mention about slot access in the logical sense. To give a parallel
generalization, lot access generalizes to method calls in the following
way:

(1) The slot name becomes the method name.

(2) A single object argument becomes possibly-multiple arguments, with
possible meta-information such as an argument's type. It's now a dispatch
configuration; actually, a single argument / implicit context argument is
a trivial dispatch configuration.

(3) The effect of the call will also no longer be trivial or singular. I
mean any effects including side effects, not just return value(s).
Actually, object systems with meta-object protocols allow non-trivial slot
accessor effects as well.

Your characterization of selection in this paragraph is confused by
comparison. I can't even determine what "this kind of object" refers to.
If you mean the code body as the selection, then that is very confused
indeed, since you previously claimed that the /name/ of a slot access
corresponded to the selected object.

> I hope that's clearer now. There's a couple of research papers somewhere
> on the Web, but they're rather low-level and look at the system from a
> lambda-calculus angle, not from the object-based language angle. And the
> original motivation had nothing to do with objects anyway, it was an
> attempt to generalize term rewriting systems. I discovered the object
> connection much later.

No, it's more confused. I think you need to formalize your definitions
better. But honestly, if you're at this level of work, I don't think it
helps to hear more of this explanation from you.

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