> Hyperon is ultimately intended as an alternative to current OpenCog > Atomspace, yes.
Actually I should be more precise here. It is not yet clear whether we'll end up replacing the current Atomspace in the Hyperon system... we are open to doing so but this isn't yet decided... What is more clear is that we want to replace the current Pattern Matcher, or at very least deprecate a large percentage of its functions.... Alexey has written a bunch about why we want to do this, in the various docs linked from https://wiki.opencog.org/w/Hyperon:Atomspace (see esp. the docs linked from the bottom of the page, and links contained therein)... In short the design pattern we want to follow is to have -- a static pattern matcher (which however manages bound variables fairly sophisticatedly, and can match variables against whole sub-metagraphs...), which then also gets an efficient implementation for execution against distributed Atomspaces -- an Atomese language which is used to do a lot of the more programmatic stuff done in the current Pattern Matcher, as well as a lot of the stuff habitually done in Scheme scripts in current OpenCog usage This is different from the design pattern used in the current PM, which embeds an awful lot of sophisticated program-control functionality into the Pattern Matcher itself (thus making it way more than a pattern matcher in any conventional sense)... The current PM seems like much more complex code than the current Atomspace, but maybe I'm missing something subtle in the latter? ben -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CACYTDBeRgLNTPDMRLSP-_vsv-fD4qC9047mgZY5gB6aB_cLY8A%40mail.gmail.com.
