[
Lists Home |
Date Index |
Thread Index
]
"We as autonomous agents ALSO assign
meaning to things without negotiating with any other autonomous agents.
In other words, the significance of things can be developed (enhanced,
whatever) without negotiations."
Another point of view on this is that assignment of signs
without negotiation with other 'autonomous agents' is a
form of negotiation with the environment, that is, the
environment behaves semiotically as well. It is an
agent. When using semiotics, one should consider it
a model of process for assignment (both identity and
sign).
What you are describing is what is sometimes called,
"self-modifying code". I've been taught that self-modifying
code isn't safe code and I've accepted that as an
article of faith, so I can't verify that with facts.
Still if so, what I would ask is if XML
and XSLT (modify by transformation) is safer
than when done in other languages and if so, why?
Very neat project and thread, Roger.
len
From: Roger L. Costello [mailto:costello@mitre.org]
Hi Folks,
On Friday I had fascinating conversation with a person who has been
doing Complex Systems work for several years. Our conversation
progressed from semantics to programs which write themselves. Below I
recap this fascinating conversation. I thought that you might be
interested.
That conversation stimulated a lot of ideas in my head: I started
experimenting with creating XSLT stylesheets which can write
themselves at run-time ... and have succeeded! So, after the recap I
talk about that exciting work.
--------------------------------
Recap
Semantics - the study of meaning; the internalization of negotiations.
Imagine living on a desolate island. There would be no shared
semantics.
Semantics comes about via negotiations - people negotiate an agreement
on what things mean. Things take on meaning when we internalize
those negotiations. Consequently, semantics is a highly individual
thing.
Ontologies are a representation of prior negotiations. This
representation dilutes individual (unique) perspectives.
Think about a message. What are the semantics of that message? It
has no semantics by itself (or, rather, very little). The code which
processes that message embodies the full semantics of the message. The
code is an internalization of the negotiations that occurred at
development time among developers.
The most important insight that comes from the recognition that
semantics is linked to negotiations is that in almost all software
contexts today, the negotiations have stopped when we get to "run-time".
The negotiations happen mainly at "development time".
Lesson learned: ways to improve semantics (interoperability):
a. Improve the internalization of negotiations at development time,
i.e., improve dialogue/collaboration among developers.
b. Collapse the separation between development and run-time, i.e., the
internalization of negotiations occurs at run-time, rather than
development time. In other words, programs write themselves!
In the early 1900's there was a prediction that with the tremendous
increase in telephone usage it would soon come to the point where every
man, woman, and child would have to become a telephone operator! Of
course, that didn't happen. Why? Because the telephone switch was
invented, which (mostly) obviated the need for telephone operators.
We are in a similar situation today. With the tremendous increase in
software needs people are predicting that to meet our needs every man,
woman, and child will need to become a programmer. Of course, that
will never happen. Why? Because someone will develop a way for
programs to write themselves.
Let's experiment with ways to design programs which write themselves.
Let's start small. Perhaps we make 99% of the program with fixed
semantics and 1% of the program rewrite itself based upon interaction
with the environment.
Consider a tree: 99% of the tree is fixed. It is only the outer part
(the bark, the leaves) which is constantly changing (rewriting itself),
based upon negotiations with its environment.
Note that XSLT has the ability to output a stylesheet. Thus, it may be
possible to create a stylesheet which outputs a modified version of
itself, based upon the input (environment).
-----
Corrections/Clarifications
The person that I spoke with on Friday corrected/clarified some of the
above notes:
"Semantics is the label most of us give to the significance (meaning) of
what is internalized in negotiations. This does not happen as the
consequence of a sequential process. We don't negotiate and then
internalize and then go back to negotiating, and so on. Both can go on
continuously or concurrently.
Semiotics is the name that is given to that process or at least to
understanding how that process works. But semiotics includes more than
just internalizing negotiations. We as autonomous agents ALSO assign
meaning to things without negotiating with any other autonomous agents.
In other words, the significance of things can be developed (enhanced,
whatever) without negotiations.
Meaning that is not shared is difficult to talk about (share with
others) for obvious reasons. It exists, but we can't share it without
destroying it at the same time."
--------------------------------
(XSLT) Programs which Write Themselves
I have written a stylsheet which computes a function, f(x, y), where x
and y are inputs. The stylesheet is initially coded to compute:
f(x,y) = (2 * x) + (2 * y)
For this input:
<f>
<x>10</x>
<y>10</y>
</f>
The stylesheet will output:
f(x,y) = 40
The stylesheet is quite interesting. It has the ability to
dynamically modify itself, based upon instructions from the input - the
input can direct a modification to the stylesheet, e.g.,
<f>
<x>10</x>
<y>10</y>
<modify-y>3 * y</modify-y>
</f>
This input is directing the stylesheet to rewrite itself, to
compute the function:
f(x,y) = (2 * x) + (3 * y)
The stylesheet rewrites itself by outputing a new version of itself.
The new version implements the new function. The stylesheet is
a self-reproducing, self-modifying program.
I have coded the stylesheet so that most of the semantics are fixed.
That is, the operation on x, (2 * x), is fixed, and the addition of the
two operands is fixed. The only portion that is changeable is the
function on y. Thus, like a tree, most is fixed but a portion is
changeable by interaction with the environment (input).
Here is the URL to the initial stylesheet:
http://www.xfront.com/cas/f.xsl
If you examine it closely you will see that it implements:
f(x,y) = (2 * x) + (2 * y)
Here is the URL to the stylesheet after interacting with an input that
instructed it to rewrite itself:
http://www.xfront.com/cas/f_v2.xsl
If you examine it closely you will see that it implements:
f(x,y) = (2 * x) + (3 * y)
Thus, by interacting with its "environment" the stylesheet program has
modified its semantics at run-time!
My next challenge it to modify the Game of Life so that it can rewrite
its semantics at run-time. Your suggestions are very welcome.
|
