From: Mark Waser (mwaser@cox.net)
Date: Mon Mar 15 2004 - 21:13:02 MST
> > > IMPORTANT POINT: If I were Ben and working on Novamente, I
> > > would be making sure that my freezing and thawing (storage
> > > and retrieval) of schemas, atomspaces, etc. was available
> > > through XML and that Sasha 2's syntax was XML compliant.
>
> I really don't see the practical use of making Sasha (an
> as-yet-unimplemented programming language for specifying
> Novamente-internal procedures and knowledge structures) XML-compliant,
> though....
In order for the system to self-modify programming, Sasha should be (as you
state below) in the form of the basic Novamente data structures. These
Novamente data structures should easily translate into XML.
> Pretty much, the use of a Sasha procedure to humans is only inside other
> Sasha programs.... And, Novamente will not analyze Sasha programs as
> series of text characters anyway -- it'll analyze them as data
> structures (CombinatorTrees, CombinatorDAG's, etc.). Once a Sasha
> program has been interpreted into a combinator tree, whether its source
> code was XML-compliant or not is irrelevant, isn't it?
Once the program is interpreted into a combinator tree, the source code is
irrelevant. For parsing to get it into the tree, for storage and,
particularly for retrieval, it could be VERY useful to use a lot of the
standards and infrastructure already developed for XML. One thing which I
haven't seen yet in Novamente that I'm sure will be necessary is ways to
partition an atom space, label the pieces, and provide efficient and
scalable directed access to specific pieces (and only those pieces) when you
need them.
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:46 MDT