Term "Configuration"

[Brian T Rice]

On Tue, 22 Apr 2003, Mario Blazevic wrote:
> >>Brian T Rice <water@tunes.org> said:
> >[Omitted return-multiple-values example.]
> [Omitted multiple-values formulations as configurations.]
> I may be off track, but what you're describing here starts to resemble
> the thing I've been working on, well on-and-off, for the past several
> years. If I'm right, a configuration is a very general version of what I
> call environment. The difference is that environment is just a mapping
> from labels to terms, there's no meta-level interpretation. A label is a
> term. An environment is a term. And having two terms, you can combine
> them into a "sequence", which in case of two environments is an
> asymetric union, or a "selection" which is really the result of one term
> evaluated in the context of the other.

Well, for one, you can't identify everything with terms, since that binds
your language to a specific level of structures. This can be excepted if
you have a language whose syntax (the forms of the terms) can be locally
modified so that term types can be adapted dynamically to the situation,
as in Maude (although Maude users don't exercise this capability in a
nested manner very much). Even so, terms have a configuration of their own
as a syntactic form. Being able to identify this with an actual
configuration at run-time and being able to dispatch on more complex
configurations (directly expressed by terms) is a powerful feature of
declarative languages.

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.

> 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.

However, what you say about the result of the function call does agree
with my understanding of the situation, although I'd prefer to speak of
the context's configurations or some configurations applying to part of it
that the function modifies. There is some sort of "principle of minimal
expression" here that I think is worthwhile. As for threading
side-effects or the piecemeal idea, this appeals to me intuitively, but I
don't see an immediately clear formulation of it just yet, though I would
like to. Perhaps you can get an idea from how I described these issues.

> >There's also the case that the values are attributes of the
> >computation, such as 'dummy locals' for "quotient" and "remainder" for
> >integer division.
> I'm not sure what you're trying to say. Are quotient and remainder
> actual locals, unaccessible outside of the computation, or are they
> parts of the result you can ignore?

Well, in this case, I'm saying that we can allow for the blurring of the
concept of locals and "parts of the result". For example, in Self or
Slate, a block closure's locals are just slots on the block object, and
there's no necessary principle of privacy there. Labelling partial results
with a local and having some way to access this state as needed from the
caller amounts to providing the kind of solution to multiple-values
generalization that I am suggesting. Specifying that local as being
single-assignment only allows the compiler to avoid some analysis and
treat it as intended: as a possibly-unused label. In an context inlining
that call within another call, the accessing of this "alternate value"
from that local would determine whether the generated code would even use
this local.

> >Your multiple bindings example could be done via expressing a
> >configuration of quoted terms, perhaps. I'm not sure what the correct
> >analog is; perhaps the configuration itself would be quoted. Or you
> >could simplify this by serializing the configuration and using a list
> >of variables (attributes) to bind to them.

> It can also be treated as pattern matching (in the functional language
> meaning, not Perl) of the pattern (x,y,z) on the configuration/
> environment returned by the function. The requested attributes are
> extracted from the function result and the rest are dropped. A very good
> implementation could figure out that the dropped attributes don't need
> to be computed and generate an optimized version of the function. Is
> that what you meant?

Well, pattern matching in the terms I've been working on for TUNES would
be a type of dispatch (http://cliki.tunes.org/Dispatch) on a tree-shaped
configuration that dealt with first-order attributes (value and structure)
and type-level attributes. That's how I interpret your description there,
and according to that I definitely concur with the rest.

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