From: Mark Waser (mwaser@cox.net)
Date: Mon Mar 15 2004 - 21:01:54 MST
> The problem is that unless this XML/prog-lang mapping is done in a very
> simple, manageable, compact way, it's not of any practical use...
Agreed but I don't actually see much complexity here. Fundamentally, most
programming languages are actually very small. It's only when you consider
functions and function libraries as a part of the language that they seem
large.
> Honestly, I think what you want is Refal.NET (which doesn't exist of
> course, but would be a fun port to make. Some friends of mine have now
> ported OCaML, another weird functional language, to .NET ... The port is
> called Nemerle)
Actually, Sasha2(the XML version).NET would be pretty cool if you added a
couple of the features discussed below to Novamente.
> Yes, we use XML as one option for saving/loading. However, it's very
> very slow to load large XML files into Novamente, so for repeatedly
> loading the same data we load it in from XML *once* and then save a
> binary "net image" file, which can be loaded and reloaded much faster.
I agree. For "internal use only" saving and retrieving, using a binary "net
image" file makes the same sense that using compiled code rather than the
original XML schema makes. For transferring knowledge to somewhere else,
XML is probably what is needed.
> There are processes for "encapsulation" but none that specifically
> address scale-invariance; I'm not sure what you mean...
The encapsulation that I'd like to see first is the ability to represent the
specification of a schema (as opposed to it's entire operation) merely by
it's signature and functionality so that it can be more easily analyzed and
operated on by higher level schema and also so that it can easily be
replaced by other versions as discussed in the next paragraph.
Scale invariance is probably a long discussion but I'll try to hit a few
high points to give a general idea. In nature, there are a lot of
fundamental equations (like the power law) that occur at all scale levels.
Similarly, there are functions and operations that do the same fundamentally
similar things at wildly different scale levels OR in wildly different
domains. In the real world, we tend to recognize these things because they
have the same names and often serve as metaphors for each other (side
comment - it is probably worthwhile to look further into the importance of
naming in concept mapping, metaphor recognition, etc. as a way for Novamente
to better utilize learning and concept formation that was done in the real
world). I think that there is a lot of information that can be leveraged
for learning from this.
> >and b) a way to compile specific time-critical
> > schemas from more general schemas (and the reverse, allowing
> > for subsequent description of currently compiled code, like
> > CIM-dynamics, WITHOUT affecting the system).
>
> This is something that we know we need, but have not yet thought about
> in detail. This would take the form of specific "graph rewriting"
> algorithms acting on CombinatorTrees and CombinatorDAGs ... Comparable
> to what exists inside some functional language interpreters. But this
> is not a good discussion for SL4, I suppose -- too narrowly technical...
Graph rewriting is awfully vague, generic, and covers a lot of ground. I
think that one important trick (that will take a long time) is recognizing
when you have a generic function that can be generalized, compiled and added
to your toolbox. Another trick (that should happen sooner) is recognizing
when all that is needed is a subset of a slow algorithm and when you can
constrain the algorithm and use variable folding to transform an overly
time-intensive algorithm into a supportable one. Another trick (that you've
already used) is to be willing to replace whole graph sections with
human-created code where appropriate. Actually, an example is probably
appropriate here since this also feeds into the encapsulation/scale
discussion. For example, sorting/sorted is a generic operation/concept that
CAN be represented in combinatorial logic - - but I would prefer to have it
generally encapsulated as a description with the actual code being compiled
from some nice hand-crafted C++. Your CIM-dynamics are clearly already this
type of code but you want to be able to, eventually, also allow the system
to see the Combinator version of the algorithms. At some point, the full
transition from Combinator to compiled code should be possible . . . .
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:46 MDT