Term "Configuration"

[Brian T Rice]

On Sat, 12 Apr 2003, Massimo Dentico wrote:

> Now it is clear that the definition of /term/ is mostly syntactic.

Yes, unfortunately I failed to distinguish between the natural language
use of "term" in the subject line with the formal syntactic use of the
term in the rest of the mini-essay.

> So on  Wed, 9  Apr 2003  16:37:46 -0700  (PDT), when  you (Brian  T Rice
> <water@tunes.org>) wrote:
>
> > It occurs to me that the same configuration concept could be used for
> > both purposes.  We could cover the collection-like or -based
> > requirements with such concepts, and this seems to blend well with the
> > idea of terms.
>
> are you alluding to possible interpretations (semantics) of the /term/
> concept? I think to be so.

To rephrase: there appears to be a concept more general than both the
collection notion and the notion of an expression term-tree, and that this
concept seems to encompass both of them. Since you don't quote the
explanation of "configuration" earlier, I will assume that this is
understood well enough.

> This remind me about two  possible kind of collection (set)  definitions
> (to simplify the exposition here I'm ignoring some details when I equate
> collections and sets, such as order, multiple instances, etc.):
>
> - /Intension/: a definition of a Set by mentioning a defining property.
>
> - /Extension/: the definition  of a Set  by enumerating its  members. An
>   extensional definition can  always be reduced  to an Intentional  one.

This works well in mathematics, but we are not directly dealing with
mathematics. :P For example, saying that "an extensional definition can
always be reduced to an intensional one" is useless to a programmer unless
a shorter program to generate the same thing can be made. Otherwise the
"intensional definition" is trivially equivalent to the extensional one.

Anyway, I think this is totally beside the point. This seems to relate
more to the notion of separating implementation from specification.

> Your examples are apparently of the second kind here:
>
> > Indeed, terms are often thought of as collections: Lisp uses lists,
> > people here have mentioned "tuples"  (with whatever meaning they
> > intended), and Slate uses objects with attributes, some of which are
> > different kinds of collections (mostly Sequences).
>
> but I'm quite sure that the first is implicit in your discourse (for
> example:  in Prolog a variable plays often the role of a set via
> backtracking and unification).

You're making a useless distinction between extension and intension. For
example, Lisp does not have to use actual list data structures for its
syntactic structures, but lists are its means of expressing them and
understanding them.

> > This sounds great, but the idea needs to reach some definite
> > formality; something we can see implementing. We can talk about a set
> > of objects:  a minimum amount of collection information to say that
> > some objects are part of a configuration, just that "they belong".
> > With higher-orderness, we can use this idea to say that attributes
> > also "belong", although this kind of reflection required for just an
> > argument list is a lot of overhead at runtime which just should exist.
> > So there should be optimized versions (subtypes)  of this
> > implementation, specialized for specific cases.
>
> This is not clear to me: collection-oriented languages use intensional
> (operators and functions) and extensional (some syntax for literals and
> enumeration)  terms in expressions even if there are some more
> declarative and other more operational. Note that even in this case you
> can often establish, under some constraints, some equivalence; for
> example between relational algebra, which is, in a sense, more
> operational, and the relational calculus of domains or tuples, which are
> more declarative.

See, this definition of intensional vs. extensional is just confusing you.
"some syntax for literals and enumeration" is still an "intensional"
definition, unless you are rabidly concerned with the rigor of Algorithmic
Information Theory that all expressions be "shortest possible programs",
which has absolutely nothing to do with this concept. A "configuration"
models "a state of affairs" if you will.

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

Configurations which are /not/ term trees are merely those describing
actual relationships between objects which have no /direct/ origin in the
form of expressions.

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