Frankly, it is often my impression that these things look simpler when in books than they are when you actually go to implement them. :wink:


Actually, for what it does, Prolog is very fast. If you were to implement such a prover yourself, you'd very likely end up reimplementing a lot of what the Warren machine does. I've worked in this field (logic) quite a bit actually. My MS was in AI with focus on logic, so implementation obviously came up alongside various theoretical concerns.

In a particular class I took and taught, programs with their own logic engines (including mine, FWIW) were invariably slower than programs that embedded Prolog.

But you are correct that Prolog is not a full FOL theorem prover. It's not really that its semantics are theoretically simpler, they're just different. (Herbrand vs. non-Herbrand interpretations, etc.)

A full FOL theorem prover is however likely to be far slower than Prolog. :shrug: It really comes down to what you need it to do. You might not have a choice in the matter, and need full FOL. But as I said, in practice a lot of people in the field use Prolog or something with similar semantics.


Well, once you do the parsing, the strings are basically incidental, as you are dealing with logical structures, not strings.


It's not just that it wouldn't cope well – it wouldn't be able to solve the problem in the first place. :wink:

Big, big difference between parsing commands and even strings into parts and/or parts of speech, and doing any kind of semantic analysis on the results of your parsing. "NLP" is a lot more than just parsing things.

As I said, I have only read a few books on the subject including Blackburn's. So take this all with a grain of salt:



Always :tongue:. More seriously though I think this generally depends on how clear the material is presented and how laborious the work is. Looking over what was presented in Blackburn the parsing -> FOL step was very clearly presented and it appeared you could almost cut and paste the algorithms into some language and get them to work. It seemed about as straightforward as writing the compiler to IL layer which I am working on and off on atm. The book actually piqued my interest enough that I might actually try doing this- but it seems like without a good lexicon I am sort of stuck.



Hmm. I never heard this before. I always hear that Prolog was the result of some compromises to get a computationally tractable "subset" which is decidable. with negation as finite failure and procedural like cuts etc.



Well Blackburn doesn't seem to like if IIRC since for certain english sentences in the representations he describes it just unfortunately is inadequate. He suggests using an open source theorem prover to do this job.



Well you might be able to coerce it to- using something like a combination of C + PL/SQL or some such but I speculate it would be painful and quite slow. Representing term like structures in tables would I think be quite a nightmare. Better to rely on the latest term indexing techniques for that.

First step is still to have a parser that can deal with the typical structure and ambiguities of natural language. Beyond that, parse_string can do a bit more then split a string into parts by using production rules that can call native logic (lpc functions) that can manipulate the data (often used in 'simple' cases to directly interpret fragments, ie, assign 'meaning' to them)

Its far from a complete canned solution, and nothing that doesn't exist in other ways also, but it does address the initial parsing phase of nlp very well in a mud environment.

I'm going to assume you're talking about relative straightforwardness again because we just had a whole discussion about why that isn't a simple problem :tongue:
But Blackburn's book is a pretty good one. We probably read the same one, although I can't remember the title.


Well, it's not really a subset, that's what I meant. I don't really mean to get into a theoretical logic religious war here, but I wouldn't call it a simplification per se. NAF for example is a choice made in how you describe the world. If you can't prove something, is the negation true? Or if you can't prove something, do you know nothing about it? In standard FOL, the inability to prove p(x) simply means that you can't prove it. In NAF, the inability to prove it means that it is false. Is that a "simplification", or just a different way of looking at the world? Definitely not a subset, though, because the rules are quite simply different.

Cuts are IIRC a programmer's tool, and are useful for efficient programming of complex recursions, but I don't believe they are strictly speaking necessary. To be honest I haven't used them much.


I have to admit that I don't remember all the details of his representation. It's possible that you do need a standard theorem prover, yes. But it's also possible that he was trying to do more with the language than we'd like to here.

If you want the mud to revolve around the chat bot it'd probably be easiest to use Socketmud. It's a barebone codebase in the public domain which will leave your options wide open if you ever want to release the source code.

NakedMUD is built on top of SocketMUD, and is much more in a useable state without sacrificing the options you could have. It is also very actively developed. The developer releases approx. every 6 months, and is frequently in the dev chat channel to answer questions or give you examples of how things could be done with NM.

Hi everybody. Thanks so much for the replies. I realise natural language is a big area. Without aiming for anything too ambitious, I might just stick to my original attempt at 'looking for topic word'. My guess is with a good dictionary at hand and a not so complicated engine, it should be possible for my bot to look up this dictionary however many thousand times and make a pretty good guess at the current topic. That's my hypothesis. I will stick with LPMUD for a bit longer. I am using Dead Souls 2 on FluffOS at the moment and the combination is just great. See how far I can push things and if bottle neck occurs I'll then change over to something else. Thanks again for all the help and suggestions from everyone.

I would suggest not dismissing "Eliza-bots" too quickly. You can do an awful lot if you throw in a little bit of state to Eliza. You might not get the full chain of inferences that you gave in your example, however you can do something fairly passable. Eliza itself has fooled people from time to time, and with just a little bit of contextualization it can be even better.

IMHO you get an awful lot out of slightly nicer conversation compared to no conversation at all. Nobody is expecting full AI here, being able to give the mobs word puzzles and the like. (Well, if they are, it's not a reasonable expectation I'd think.)

Forgive me, as I haven't been following this stuff lately, but how does your bot understand the definitions it "looks up"?

I would expect a thesaurus to be more useful than a dictionary.

Keep in mind that with any codebase you're bound to find limitations on one thing or another as to what you can do. The goal here is to find ways around said limitations. No matter which codebase you use, you're better off sticking to what you know than with trying to learn a whole new codebase. You can adventure out and look at all the codebases if you want, but if you've already made a lot of progress on one, why undo all your hard work by switching codebases?