What language for a thinkbot

If you want to make a chatbot, you can choose a language like Rivescript or AIML to code it. Answers are triggered from what was said before.

But if you want to make a thinkbot, a bot where thoughts are triggered from previous thoughts, what would be your dream language? If thoughts were JSON docs, then what commands would you need to make your bot?

Any decent programming language, I would say, not a scripting language that reads files to access its "thoughts". I would want to keep a great number of recent thoughts in active memory for fast access. Depends on what you mean by "thoughts" though.

1. induce new rules that hold on existing input2. deduce answers from existing input by given rules3. generate semi-random thoughts for chit-chat if you're building a chatbot

I agree, though semi-randomness is maybe not necessary if the system is complex enough.

Quote from: DemonRaven

IF you are talking about adding a memory to a chatbot the personality forge does that. I don't recall off hand what programming language it uses but some thing on that order would work.

No I'm not talking about adding a memory to a chatbot. I'm talking about another kind of bot, whose main activity is not to produce answers to the user but rather to produce "thoughts": answers to itself.

Quote from: spydaz

If thoughts were owl files

Yes, it's the same: thoughts are directed graphs, JSON docs containing references to one another. We can put OWL in them.

Quote from: ranch vermin

The problem with this is, is how did the thoughts get in there? If its just what the robot saw, then its just regurgitation of the text going in. (what you are trying to avoid.) which is what we do.

Thoughts are generated by sensing previous thoughts, and by sensing things from outside the program (like user input or web browser).

There are two difficult things with AIML: 1) you have huge files hard to maintain and 2) you end up with answers "shadowing" other answers. Moreover, AIML cannot handle structured data, but only flat strings.

Now, what if instead of strings we were using JSON pieces? We could then react on JSON patterns, and emit JSON pieces, that we would call "thoughts".

Next thing: AIML and Rivescript brains are monolithic systems, I mean: the entire system react as a whole. But we know that it is not how real brains work. Real brains have specialised areas, each of which is good at doing one thing.

So, instead of having one single system taking input from user and sending output to user, we could have "areas", taking input from other areas, and sending output to other areas. It would probably be easier to maintain (and no more shadowing since areas are specialised), and more important, we could have dozens of authors working in parallel on one brain, without interferences.

But now, the brain file wouldn't be like AIML anymore (trigger/template + trigger/template + trigger/template), it would be a little bit more complicated. We need to handle the area network topology, thoughts transfer, thoughts transforming, filtering, and probably many more things that I haven't imagined yet. Hence my question: what commands would you need to make your bot?

Quote from: Don Patrick

I would want to keep a great number of recent thoughts in active memory for fast access. Depends on what you mean by "thoughts" though.

In our case, thoughts would be kept in RAM indeed, it needs to be fast. I'm calling "thoughts" a piece of structured data like JSON, with possible reference to other data.

This one would be straightforward: this area treats information from its 3 sources the same way, no matter where it comes from. But we might want to have different trigger/template pairs for data from different sources. So I change the syntax a little, to allow different behaviors for different sources:

Wow, tabs are big. Nevermind. Now, these are independent behaviors for different data sources. But we probably want to combine data from different sources. So, instead of outputting directly through "template", we could maybe store things for later, like this:

(This is some kind of indented JSON, hopefully easier to read.)Now we have a "main" slot, which can take outputs from other slots. It would react only if it has incoming data from every sources (here slot1 and slot2). If one source didn't send anything, "main" waits. Now, slot1 and slot2 don't output things directly, they just prepare preliminary stuff for "main" to process.

This one would be straightforward: this area treats information from its 3 sources the same way, no matter where it comes from. But we might want to have different trigger/template pairs for data from different sources. So I change the syntax a little, to allow different behaviors for different sources:

Wow, tabs are big. Nevermind. Now, these are independent behaviors for different data sources. But we probably want to combine data from different sources. So, instead of outputting directly through "template", we could maybe store things for later, like this:

(This is some kind of indented JSON, hopefully easier to read.)Now we have a "main" slot, which can take outputs from other slots. It would react only if it has incoming data from every sources (here slot1 and slot2). If one source didn't send anything, "main" waits. Now, slot1 and slot2 don't output things directly, they just prepare preliminary stuff for "main" to process.

Am I understandable?

This is just an example of how things could be. But we could base it on libraries like this one for instance.

For pattern matching, would JSON Schema be overkill?

Since data is structured, we don't need to search for globs in the middle of a string. In triggers, we could use a simple glob-like pattern definition with string containing<list> if we expect an array [ ... , ... , ... ]<asso> if we expect an object { ... : ... , ... : ... }<atom> if we expect an atomic value like string or number<any> if we expect anything

Then in templates, we insert what was previously captured by inserting a string containing <2>, which will be replaced by whatever was captured in the 2nd glob.

Then in templates, we insert what was previously captured by inserting a string containing <2>, which will be replaced by whatever was captured in the 2nd glob.

I understand you very well and I think you're at a right path. I'm doing something similar, but I'm developing my own pattern recognition language that includes boolean operations on the trigger side and possible multiple results on the template side. I even think that's how humans generally think: they see something around them and that associates them on some thought, which in turn associates them on some other thought and so on.

What you are describing has more power than simple responding to a template. Consider a case where we have canonical template -> trigger expressions like e1 -> e2 -> e3 -> e4. Of course, if one trigger can have multiple templates then we get a tree of templates. This I call deduction and it is capable of deriving logical conclusions (if you enter logic formulas) or solving math problems (if you enter math formulas) or solving chemical reactions and G** knows what else. On the other side, in the other direction of deduction stays abduction that is capable of answering from what circumstances you have to start to reach some consequence (like what compounds have to be picked to get some chemical solution or answering questions: "Why are streets wet, was it raining?").

I'm not sure, but I think that you're reinventing calculus of constructions, or similar branch of science. Beware, even though I, myself am developing such a branch, I'm not an expert in those existing areas, your approach just reminds me of the branches and of my project. Nevertheless, it all sounds cool and promising to me.

Well honestly, CoC and Synth are too complicated for me to understand. I understand what they're about, but I could not use them unfortunately. I'm just trying to set up a environment in which a lot of mini-chatbots react to JSON patterns by emitting JSON.

I think I'll go with JSON-Schema for pattern matching and JSONexp for JSON construction. Maybe later use a diagramming library to build structures, but I'm not sure yet.