Term "Configuration"

[Mario Blazevic]

Brian T Rice wrote:

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

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

    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.

    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.

    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.