Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Semantics, Complex Systems, (XSLT) Programs which Write Themselves
 It seems to me that you're on your way to discover Higher-Order Functions and Partial Application. Read e.g. [1] for the detailed description of several ways to create a new function dynamically at run-time. These are standard features of functional programming languages [2] and of the FXSL library for functional programming with XSLT 1.0 and XSLT 2.0. ===== Cheers, Dimitre Novatchev. http://fxsl.sourceforge.net/ -- the home of FXSL References: [1] Functional programming in XSLT using the FXSL library at: http://www.idealliance.org/papers/extreme03/xslfo-pdf/2003/Novatchev01/EML2003Novatchev01.pdf [2] Haskell: The Craft of Functional Programming By Simon Thompson, Second Edition, Addison-Wesley, 507 pages, paperback, 1999. ISBN 0-201-34275-8. "Roger L. Costello" <costello@m...> wrote in message 3F9D2DFF.47E17EF3@m...">news:3F9D2DFF.47E17EF3@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. > /Roger > > > > ----------------------------------------------------------------- > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > initiative of OASIS <http://www.oasis-open.org> > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > To subscribe or unsubscribe from this list use the subscription > manager: <http://lists.xml.org/ob/adm.pl> > > 
|
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
|
|||||||||
