Term "Configuration"

[Brian T Rice]

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.

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

> > [..] 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).

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

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