[
Lists Home |
Date Index |
Thread Index
]
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@mitre.org> wrote in message
3F9D2DFF.47E17EF3@mitre.org">news:3F9D2DFF.47E17EF3@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.
> /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>
>
>
|
