linas, thank you for this very clear explanations.

Am Mittwoch, 20. September 2017 04:45:55 UTC+2 schrieb linas:
>
> Hi Alex, one more note:
>
> On Wed, Sep 20, 2017 at 1:23 AM, Alex <[email protected] <javascript:>> 
> wrote:
>
>>
>> If OpenCog knowledge base (AtomSpace) is the big Scheme program then we 
>> can consider also the self-modification of this program.
>>
>
> Yes. Let me try to be very clear about this: atomese is designed from the 
> ground-up to be self-modifying. This is why/how atomese differs from any 
> other programming language. Most programming languages are designed to be 
> used by humans: java, lisp, haskel, python, whatever. It is very hard - 
> basically impossible - for a java program to understand itself, to change 
> itself.
>
> atomese is designed to be used by algorithms.
>
> There are other languages that do this, but you probably have never heard 
> of them: gimple, gil, the llvm IL, and so on. These languages, although 
> they are designed to be modified/modifying, they are unfortunately very 
> special: they are designed to be internal to compilers (gimple and gil for 
> gcc, the llvm il for clang). They are not general-purpose.
>
> atomese is designed to be like gimple or gil or llvm, but general purpose 
>
> There are languages designed to modify other languages: these are the 
> "macro languages", for example: m4, cpp (the c pre-processor), (scheme) 
> hygenic macros, and the C++ template language.  Unfortunately, these are 
> designed to be run once and only once, Macros can only be expanded once; 
> you cannot expand them a second time. C++ templates can only be expanded 
> once.
>
> atomese id designed to be like a macro langauge, that you can expand over 
> and over and over.
>
> There are languages that are designed to be macro-like, but run multiple 
> times.  These are called "rule engines". Examples include DROOLS and 
> CLIPS.  However, these distinguish between the language the rules are 
> written in, and the language that is used to represent data (the "knowledge 
> representation" or KR language).
>
> atomese is designed so that both the rule language, and the KR language is 
> the same language.  Thus, in principle, rules can modify rules.  
>
> In order to be self-modifying, one has to be able to "introspect" or 
> examine the structure of relationships. There are languages that can 
> examine the structure of relationships; but these again keep data distinct 
> from the relational structure.  The most famous relational language is 
> SQL.  However, SQL can only query relations on tables; it cannot apply the 
> relational algebra on itself (except in certain very limited cases).  In 
> SQL, the KR are tables and databases, and queires are queries, they are two 
> different things.
>
> atomese is designed to provide a relational algebra, but it can be applied 
> to itself.  Both the data (the tables/databases, the KR) are written in 
> atomese, and the query language is also in atomese.
>
> One last example: there are graph databases; Matt Chapman mentioned one.  
> However, (I'm not quite sure) I suspect the graph query language is not 
> itself a graph.
>
> atomese is a graph database, and the query language is itself a graph 
> (that can be stored in the database).
>
> These are all the different ways in which atomese has been designed to be 
> self-modifying.  The goal is to steal the very best ideas from other 
> languages, and make them work in atomese.  I think that atomese is partly 
> successful in doing this, but I know that I am still learning new tricks, 
> and understanding new things.  We are not done yet.
>
> --linas
>
> -- 
> *"The problem is not that artificial intelligence will get too smart and 
> take over the world," computer scientist Pedro Domingos writes, "the 
> problem is that it's too stupid and already has." *
>

-- 
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 post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/opencog.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/opencog/3157cd38-50e3-4950-ab43-1502540a55dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to