RE: Semantics, Complex Systems, (XSLT) Programs which Write Th
"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@m...] 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.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format