Brian T Rice
Mon Apr 14 13:56:01 2003
The majority of your reply was a lot of speculation and off-topic, which I
will take to mean that this question is decided.
On Mon, 14 Apr 2003, Massimo Dentico wrote:
> On Sun, 13 Apr 2003 19:44:29 -0700 (PDT), Brian T Rice <email@example.com> wrote:
> > On Sun, 13 Apr 2003, Massimo Dentico wrote:
> >> On Sat, 12 Apr 2003 14:42:27 -0700 (PDT), Brian T Rice <firstname.lastname@example.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.
I am /not/ talking about languages or syntax. The only reason I mentioned
them was that syntactic structures have a notion of configuration among
the syntactic objects they are composed of, and there is no further
relation. The topic of this thread is "object configurations" and no
other. Syntax trees apply because they are configurations and because I
made some points about the /type/ of configuration they are.
> >>> [..] 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.
Huh? It's not a syntactic expression system (a language), it's just a
Furthermore, I have expressed no relation with data-flow or other
information-flow expression systems. Configurations should not be aware of
the direction of information flow. A configuration is just "a state of
affairs": a snapshot, whether actual or potential (and intentionally
unaware of that status). This should be incredibly intuitive.
> On Wed, 9 Apr 2003 16:37:46 -0700 (PDT) Brian T Rice <email@example.com> 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.
And your recent email makes less sense. From my point of view, you seem
unnaturally interested in identifying the idea within a totally-linguistic
context, and are doing it repeatedly despite my comments to the contrary.
> Comments and suggestions about "belong" relationship and attribuition
> will be probably the subject of an upcoming e-mail.
Try to make it concise, please.
Brian T. Rice
LOGOS Research and Development