Term "Configuration"

[Brian T Rice]

I have a term listed in my specification draft called a "configuration"
which hasn't been debated yet, and isn't documented on the CLiki yet
either. I'm not sure how appropriate it is, but I'll try to lay out my
thoughts and reasoning about this. Maybe someone here can give me a better
perspective or at least help me explain it better.

Anyway, I'll start with the listed definition in the draft:

"An object representing some requirements on the relationships between
some collection of objects."

This doesn't reveal much, to be honest, but it does describe the essence
of the idea. Actually, the later definition of Specification sheds a tiny
bit more light:

"An expression describing a configuration."

Okay, so this isn't exactly informative. Here's my thought process behind
these ideas:

We have this basic thought process behind the language we want, that says
that we call every 'thing' in the system an object, and we don't give it
any intrinsic definition. An object could be just like a Haskell or Lisp
object as it could be a hash-table style system storing "slots" and
"methods" or just a plain low-level machine-word fixnum, with attributes
being things that can be had via functions, which could be as simple as
using one machine-code operand. I've already sketched a bit of Fare's
definition of an attribute already, and this seems to suggest a correct
approach. So it's an agnostic definition.

At the same time, we're intent on having specifications and types be
available nearly everywhere: some kinds of promises that have hard
meaning, whether it's a property of some language we create within TUNES
or just some group of objects that we throw together (the difference is
supposed to be one of perspective, but let's not take that for granted).

So, there's this gap in the middle. We have languages that have
collections libraries and even collection-oriented languages (which has
its own CLiki node now :), and these give us some basic vocabularies for
talking about groups of things. And there is also the logical notion of a
term, some syntactic expression which talks about a value or the result of
the application of some operation to some values. Usually this can work
recursively to help allow for delayed evaluation, but it's in a different
sense a greater range of expressiveness about the relation between things;
a more expressive kind of dispatch, as I explained a couple of months ago.

However, none of these has to do specifically with the kind of concept
that's needed. Although it may be more accurate to say that we need a
concept which encompasses both, and is somehow simple.

I kept thinking about the fact that there were objects which had to exist,
and attributes which related them to other objects that had to hold. This
reminded me of how there was this idea I had for a module / package
requirement and provision system for Slate, where the system had to be
described as consisting of certain objects present in certain slots in a
global (but segmented through multiple inheritance) namespace object, and
how methods had to be defined on those in certain ways in order to say
that "feature X is implemented". I had borrowed the term "configuration"
from common (software) terminology since it accurately described a certain
state of the world, and works at different levels: people use it for
options and their values in files as well as directory structures and
permissions at the large scale.

For TUNES, it's a bit more general, because attributes are /not/ just
slots. In fact, they can be anything but slots; they just have to present
the same style of interface. So really, a configuration lifted to this
level of abstraction can describe functional tests, like assertions.

But here's another rub: Fare says on the TUNES site
(http://tunes.org/HLL/primitives.html) that "functions will be used and
bound according to the same protocols as ordinary objects."... of course,
this is my paraphrasing, but I don't seem to have fallen out of line with
the meaning of the original statement (which precedes it). This is really
simple when you think about single-argument functions, but what about
functions with real signatures, that make use of the previously-mentioned
ideas of expression terms?

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

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.

Well, I need to conclude this to not overwhelm. Basically, this is in
retrospect a re-explanation of one use of my old "Arrow system" "graphs"
idea, particularly for those "degenerate graphs" I used to mention,
although key-ing arrows as attributions wasn't included in that
specifically (there's a way to do it, but I hadn't gotten around to
expressing it in the implementation). If you weren't involved in TUNES
when I first mentioned all of that, don't worry, you aren't missing
anything.

Ideas, opinions, comments? Should we include/incorporate the idea? Should
we rename it?

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