Term "Configuration"

[Massimo Dentico]

On Sun, 13 Apr 2003 19:44:29 -0700 (PDT), Brian T Rice <water@tunes.org> wrote:

> On Sun, 13 Apr 2003, Massimo Dentico wrote:
>> On Sat, 12 Apr 2003 14:42:27 -0700 (PDT), Brian T Rice <water@tunes.org>
>> wrote:
>>
>>> To rephrase: there appears to be a concept more general than both the
>>> collection notion and the notion of an expression term-tree, [..]
>>
>> This is exactly what I didn't understand: collections regards objects in
>> general; terms regards syntactic objects, if you not imply their
>> denotations. It was a "mixing apples and orages" effect.
>
> Well, both collections and term-trees have "shape" which is to some
> varying degree independent of the objects contained. However, term-trees
> are like trees and graphs, whose elements determine the nature of the
> identity and scope of those collection types. Term-trees are much like
> this except that the type of the term also has an influence. (The general
> axiom is that adding or removing an element from this kind of collection
> necessarily involves altering the intrinsic value of the element.)
> However, even certain graph and non-specialized tree types can vary their
> type based on their nodes' types.

Correct me if I am wrong, you are saying: in this context, don't insist on
the distinction between superficial syntax and semantics because it is not
particularly meaningful. This is true even more for the class of languages
to which we have interested (functional/logical/rewriting) where we can,
to a large extent, reason about computations in terms of syntactic
transformations.

>> Thus was clear that I was missing something. From that springs the
>> expedient: syntactic objects -> denotations -> collection of objects via
>> intentional definition.
>
> This indeed is evident in functional languages' syntax. In fact, one could
> talk about configuration languages this way, but simple syntax will only
> be able to work with well-founded ("tree-topology") configurations. Lisp's
> #N# syntax with "syntax referent assignment" forms a modest extension
> which allows circularity to be expressed print/readably.

A short digression on textual and graphic notations:

it seems to me that this depends on the fact that a graph is more easily
interpretable from the perceptual/cognitive human apparatus if expressed
in a 2-dimensionsional space. Textual syntaxes, that usually are used
by programming languages, makes hard to express and understand a graph
structure.

I think this is the reason for which "goto" was considered harmful
in the era of teletypes or teletype-style terminals. But now, in the
era of high definition graphic displays and printers, it makes no sense
(but for this scope a table suffice so even a video terminal with the
entire characters grid addressable is adequate).

For the readers not convinced by this assertion I suggest to write
a little program (in imperative style, of course), not necessarly
with a meaning, full of "goto" and "conditional goto" (if <cond> then
goto <label>).

Then try to traslate this program into an oriented graph: code fragments
into bubbles, labels near these bubbles, arrows connecting these bubbles
for each goto and, in case of conditional goto, conditions near the arrows
(try to infer what consistency checks you need, here they are omitted for
brevity).

You will see how it is easier to understand states and state transitions
(which are what matter in imperative style) of this program.

Of course the data-flow is completely obfuscated but one presumes that
in such "unstructured" programs the data-flow is trivial (in contrary
case you could have different representations of a same program).

Ok, now back to "configuration".

>>> [..] and that this concept seems to encompass both of them.
>> Now, just to be sure:  are you saying that we can use the word
>> "configuration" to refer to both collections of objects in general and
>> collections of syntactic objects (terms in expressions)  and
>> relationships which hold over them?
>
> Yes. I should probably mention that this concept should encompass things
> like multiple return values and side-effects (or maybe an all-effects
> network which covers both by relating an object representing a
> computation to the various attributes which it calculates in the process
> of determining the result).

It encompasses data-flow and constraint propagation languages then.

>>> Since you don't  quote the explanation  of "configuration" earlier,  I
>>> will assume that this is understood well enough.
>> Apparently is so.
>>>> Expressions are always relationships/constraints between objects and
>>>> calling some of these expressions "configurations" seems  arbitrary.
>>>> Nothing wrong with this,  but what are precisely  the distinguishing
>>>> features of these configurations wrt other expressions?
>>> No, /all/  expressions are  configurations when  viewed as term-trees,
>>> not just some of them.
>>
>> Ok, now is clear and /a posteriori/ absolutely consequential.
>
> Great.
>
>>> Configurations which are /not/ term trees are merely those  describing
>>> actual relationships between objects which have no /direct/ origin  in
>>> the form of expressions.
>>
>> Thus configurations can also deal with objects /external/ to the system
>> (intended as linguistic framework)? Or: objects which have no /direct/
>> origin in the form of expressions are objects which "enter" into the
>> system via interactions with the outside (I/O), right?
>
> "Any objects" means "/any/ objects", which in TUNES means any /thing/. So,
> this is the case also for external objects.
>

I asked beacuase I noted in "[..] which have no /direct/ origin  in
the form of expressions" the emphasis on /direct/ and thus I wanted
to be sure.

Returning to your original question:

On Wed, 9 Apr 2003 16:37:46 -0700 (PDT) Brian T Rice <water@tunes.org> wrote:

> Should we include/incorporate the idea? Should we rename it?

Yes, it seems quite powerful because it encompasses many other concepts
and it is rather simple to understand if presented in the right way.
Frankly I would not know what *exactly* has confused me in your e-mail,
it now just makes more sense.

Comments and suggestions about "belong" relationship and attribuition
will be probably the subject of an upcoming e-mail.

Regards.

--
Massimo Dentico