Another worm for the NLP can...
Joao Mendes
Hey, all, :)
About fifteen to twenty years ago, I stumbled across a nifty little
language that, seems to me, _should_ be the end-all-be-all of AI
programming, although it has been (quite miserably IMHO) supplanted by
LISP.
I'm talking about Prolog.
For those of you that don't know what I'm talking about, Prolog (stands for
PROgramming in LOGic and) is simply a language of pattern matching. To be
overly simplistic, a Prolog program consists of the following:
- A series of statements that describe logical truths
- A single question, in one of the forms:
- Is the statement f true?
- For what values of x is the statement f(x) true?
As the program runs, the runtime proceeds to try to come up with a final
answer for the question, using the described truths.
I'm sure I've stepped on a myriad toes with the above, but trust me, it is
_very_ powerful. I've been known to state that the only real programming
languages in the world are C++ and Prolog and everything else is a
wannabe... unless you want to do something for which a highly specialized
tool exists, like, say, writing IF... ;)
One thing, though: out there, there exists a prolog program that generates
a prolog program that is... (drum roll) a parser! (tadaa) The input for the
parser generator is as simple as an EBNF file.
Ok. For those of you that don't know, EBNF stands for Extended Backus-Naur
Form and is a rather intuitive way of describing grammar rules.
Now, the interesting thing is, although NLP may well be the ultimate AI
problem, an (extended) Infocom-like syntax could (probably) be described in
under two pages of text using EBNF. Furthermore, extending the grammar
with, say, a new type of sentence, could (again, probably) easily be done
in under twenty lines.
Now, before anyone starts to respond to this, I must state quite clearly
that, at this time, I have no intention of undertaking the task of writing
a new authoring system. (Although, now that I have typed this cute little
article, the thought is entertaining itself by circulating endlessly around
in my mind...) However, all this information may be interesting to those of
you out there for whom that very thought has actually materialized into a
goal.
Additionally, for those very people, a word of caution: do _not_ take the
above as encouragement. But if your mind's made up anyway, hey, it might
just help ya. ;)
(Hoping none of you have fallen asleep at the keyboard...)
Cheers,
J.
Richard Bos
> About fifteen to twenty years ago, I stumbled across a nifty little
> language that, seems to me, _should_ be the end-all-be-all of AI
> programming, although it has been (quite miserably IMHO) supplanted by
> LISP.
>
> I'm talking about Prolog.
I tried that, once. It's probably a combination of my Prolog skills and
my IF skills, both of which are dubious, but it didn't work very well.
Getting input was ugly, and while the actual game code worked, it was
rather a hack.
However, I did end up with the feeling that if you could program the
engine in some other language (because this was the part for which
Prolog didn't work well at all); and the game itself, if not in Prolog,
then in a Prolog-like language more specifically adapted to IF; that
this might be a very powerful combination indeed.
If I had the skills, time, or inclination to write YAIFL, it would
probably be a Prolog-like language that compiled to one of the existing
engines, probably ZCode. Unfortunately, or perhaps not so, I have none
of the above.
Richard
Dan Schmidt
| Hey, all, :)
|
| About fifteen to twenty years ago, I stumbled across a nifty little
| language that, seems to me, _should_ be the end-all-be-all of AI
| programming, although it has been (quite miserably IMHO) supplanted by
| LISP.
|
| I'm talking about Prolog.
People have been kicking this around for a while; I remember that Philip
Goetz was a big Prolog fan. Here's one post:
http://groups.google.com/groups?selm=54g91v%24j2q%40prometheus.acsu.buffalo.edu&output=gplain
I don't remember seeing any resulting Prolog IF, but that doesn't mean
it didn't happen.
Dan
Adam Thornton
>People have been kicking this around for a while; I remember that Philip
>Goetz was a big Prolog fan. Here's one post:
I *think* Phil Goetz actually did his Ph.D. thesis on Prolog-based
IF/NLP.
Adam
John
this type of problem. I have programmed in Prolog before as well as
creating some rule-based systems for my job. Its very interesting. I don't
feel that I am really programming. Really what I am doing is specifying
rules. This is not easy by any stretch.
If someone wanted to create a replica of a current gaming system using
different technologies I would definitely suggest Prolog. As it happens, I
am creating something different, where I don't see that Prolog would be as
useful.
John.
"Joao Mendes" <public...@anywhere.invalid> wrote in message
news:Xns924645FEF5002j...@194.65.14.150...
Joao Mendes
Hey, :)
Dan Schmidt <df...@dfan.org> wrote in news:uofdh3...@dfan.thecia.net:
> Joao Mendes <public...@anywhere.invalid> writes:
>
>| I'm talking about Prolog.
>
> People have been kicking this around for a while; I remember that
Hey! Then I am not crazy!! COOL!!! :):) Seriously, though:
> Philip Goetz was a big Prolog fan. Here's one post:
>
> http://groups.google.com/groups?selm=54g91v%24j2q%40prometheus.acsu.buf
> falo.edu&output=gplain
I just read this. Yes! Is this guy still around?
Cheers,
J.
John Colagioia
[...]
>I'm talking about Prolog.
Quick rant, because I have places to be...
While, yes, you can write adventure games in Prolog, and
you'll even have some textual support for it:
http://www.amzi.com/AdventureInProlog/advfrtop.htm
there are a couple of key problems.
First, and I don't want to offend anybody's sensibilities,
Prolog is kind of vile. It is to rule-based programming
what C++ is to object-oriented programming. It carries
lots of dogma, and acts too much like C or BASIC when it
would really matter (cuts, anybody?). If you're planning
to take this route, consider a more modern language, like
Mercury or HOPE, which I hear has overcome many of the
major "disabilities" of Prolog.
Second, rule-based engines are typically slow, because
the runtime engine basically performs a depth-first
search on all possibilities, choosing the "closest
match" (except for Prolog, which optimizes, and then
lets you worry about things like the fact that
reordering your rules might cause a failure to match).
Finally, because of the rule-based nature of the
system, it's pretty hard to do anything *other* than
parsing. In particular, you really don't have anything
like persistent data (objects, for example), so lots of
convoluted code is required to maintain the simplest
bit of your game universe. If you don't believe this,
take chapter 7 of the aforementioned book as a good
example. See if you can figure out how to add a
description to each room (that is only written the
first time you enter, or when the user types the
equivalent of "look")...
[...]
L. Ross Raszewski
>Joao Mendes <public...@anywhere.invalid> wrote:
>[...]
>>I'm talking about Prolog.
>
>Quick rant, because I have places to be...
>
>While, yes, you can write adventure games in Prolog, and
>you'll even have some textual support for it:
> http://www.amzi.com/AdventureInProlog/advfrtop.htm
>there are a couple of key problems.
It occurs that there's a fundamental similarity to a rule-based
language like prolog and, say, a database language; a query in prolog
of the form 'is fact x true' basically means 'does there exist an
entry in my table of rules for this fact', and 'for what values of x
is this fact true?' is essentially a select operation. This always
gets me wonderign if something like PL/SQL could be used for IF --
obviously, the work involved in making this non-clunky would be
tremendous, but it does bypass a lot of the things that make IF fit so
ill-well in more mainstream languages; the weakness of static data
declaration, the extremely lightweight object model, etc.
Just a thought.
Joao Mendes
Hey, :)
"John Colagioia" <JCola...@csi.com> wrote in
news:3d2a...@excalibur.gbmtech.net:
> Joao Mendes <public...@anywhere.invalid> wrote:
>>I'm talking about Prolog.
> Quick rant, because I have places to be...
Okie. :)
> While, yes, you can write adventure games in Prolog, and
I wouldn't think of it! Well, I would, but that's not what I was talking
about. I was only talking about the parser bits.
> First, and I don't want to offend anybody's sensibilities,
> Prolog is kind of vile.
I think it's aesthetically perfect, myself. :)
> It is to rule-based programming
> what C++ is to object-oriented programming. It carries
> lots of dogma, and acts too much like C or BASIC when it
> would really matter (cuts, anybody?).
And this is bad because...
> If you're planning
> to take this route, consider a more modern language, like
> Mercury or HOPE, which I hear has overcome many of the
> major "disabilities" of Prolog.
Never heard of these. Will definitely check them out.
> Second, rule-based engines are typically slow, because
> the runtime engine basically performs a depth-first
> search on all possibilities, choosing the "closest
> match" (except for Prolog, which optimizes, and then
> lets you worry about things like the fact that
> reordering your rules might cause a failure to match).
Granted. Then again, most machines today are what, 1 GHz?... (Man, I feel
obsolete...)
> Finally, because of the rule-based nature of the
> system, it's pretty hard to do anything *other* than
> parsing. In particular, you really don't have anything
> like persistent data (objects, for example), so lots of
> convoluted code is required to maintain the simplest
> bit of your game universe. If you don't believe this,
> take chapter 7 of the aforementioned book as a good
> example. See if you can figure out how to add a
> description to each room (that is only written the
> first time you enter, or when the user types the
> equivalent of "look")...
Eh... This depends on the implementation. As I recall, Borland's Turbo
Prolog had predicates to which truths could be added and deleted, thusly
being stateful. Of course, one might argue that this isn't 'pure' Prolog
anymore, but I was never one for formalisms. ;)
In any case, you are correct. Trying to do the whole game engine in Prolog
would be overkill. However, it does feel rather perfect for the parser
bit... ;) IMHO, anyways...
Cheers,
J.
John Colagioia
>Hey, :)
Hey, back!
>"John Colagioia" <JCola...@csi.com> wrote in
>news:3d2a...@excalibur.gbmtech.net:
[...]
>> It is to rule-based programming
>> what C++ is to object-oriented programming. It carries
>> lots of dogma, and acts too much like C or BASIC when it
>> would really matter (cuts, anybody?).
>And this is bad because...
Because at the key points where you'd like to rely on "the
system takes care of all the logic for you"--any complicated
and potentially bug-ridden set of choices--you have to think
about how the engine does things, and program your rules so
that the "standard logic" will process them correctly.
I actually have some Prolog rules that I had to reorder
because--get this--the order in which I originally defined
them caused the engine to fall into an infinite loop.
For reference, I had to rewrite about 10% of the rules,
because the were (of course) dependant on each other.
>> If you're planning
>> to take this route, consider a more modern language, like
>> Mercury or HOPE, which I hear has overcome many of the
>> major "disabilities" of Prolog.
>Never heard of these. Will definitely check them out.
They're fairly new, for programming languages. Neither has
really caught on, but I've heard good rumors.
I actually had a grammar-based replacement system, once,
that would obviously be perfect for parsing, but it was
mostly a joke, so it was dead slow and overly constrained.
>> Second, rule-based engines are typically slow, because
>> the runtime engine basically performs a depth-first
>> search on all possibilities, choosing the "closest
>> match" (except for Prolog, which optimizes, and then
>> lets you worry about things like the fact that
>> reordering your rules might cause a failure to match).
>Granted. Then again, most machines today are what, 1 GHz?... (Man, I feel
>obsolete...)
Heh...It depends on what you mean by "most" and "today."
Regardless, though, a language with a slow runtime is only
going to be fast for smaller applications. Over a certain
size, and things go bad far too quickly.
>> Finally, because of the rule-based nature of the
>> system, it's pretty hard to do anything *other* than
>> parsing. In particular, you really don't have anything
>> like persistent data (objects, for example), so lots of
>> convoluted code is required to maintain the simplest
>> bit of your game universe. If you don't believe this,
>> take chapter 7 of the aforementioned book as a good
>> example. See if you can figure out how to add a
>> description to each room (that is only written the
>> first time you enter, or when the user types the
>> equivalent of "look")...
>Eh... This depends on the implementation. As I recall, Borland's Turbo
>Prolog had predicates to which truths could be added and deleted, thusly
>being stateful. Of course, one might argue that this isn't 'pure' Prolog
>anymore, but I was never one for formalisms. ;)
It's also nonstandard. And I haven't seen Turbo Prolog in
far too many years to think about...
>In any case, you are correct. Trying to do the whole game engine in Prolog
>would be overkill. However, it does feel rather perfect for the parser
>bit... ;) IMHO, anyways...
Actually, has anybody done any object-oriented parsing? I
read an article not too long ago describing it as being
fairly nice, but didn't provide any useful implementation
details.
David Brain
(L. Ross Raszewski) wrote:
> It occurs that there's a fundamental similarity to a rule-based
> language like prolog and, say, a database language; (snip)
> This always
> gets me wonderign if something like PL/SQL could be used for IF --
> (snip)
Isn't this was Kodrik was doing? What happened to his engine?
--
David Brain
London, UK
Fraser Wilson
> Actually, has anybody done any object-oriented parsing? I
> read an article not too long ago describing it as being
> fairly nice, but didn't provide any useful implementation
> details.
Yes. I've found it useful for highly structured grammars
(e.g. programming languages, particularly from the Algol family). If
you have an EBNF, then you can pretty directly map named rules to
classes, and choice-only rules map to inheritence. E.g. a Statement
rule maps to a Statement class, and an If-statement maps to an
If_Statement_Class, because it's one of the choices for the statement
rule.
This sort of thing makes semantic analysis and code generation quite neat.
I can't imagine that the limited IF grammar is particularly amenable
to this sort of thing though. However, there's more than likely
another way to apply it that I haven't thought of.
Fraser.
Joao Mendes
Hi, :)
"John Colagioia" <JCola...@csi.com> wrote in
news:3d2d7f33$1...@excalibur.gbmtech.net:
> Joao Mendes <public...@anywhere.invalid> wrote:
>>Hey, :)
> Hey, back!
;)
> I actually have some Prolog rules that I had to reorder
> because--get this--the order in which I originally defined
> them caused the engine to fall into an infinite loop.
Yuck! And probably not very Dijkstra-like... But I see your point. Then
again, infinite loops are no strangers to imperative languages... :)
> Regardless, though, a language with a slow runtime is only
> going to be fast for smaller applications. Over a certain
> size, and things go bad far too quickly.
I see your point. But (and again, referring to Turbo Prolog), I once built
an implementation of a (rather basic) conversation bot, that could even go
back to previous subjects, and had a _ton_ of rules and it worked pretty
fast. And we are talking about some 15 years ago, so...
I really believe that if your grammar is well specified, parsing should be
a breeze for an arbitrary number of rules.
For clarification, we are talking about parsing the player input, not
parsing the game description language...
>>> parsing. In particular, you really don't have anything
>>> like persistent data (objects, for example), so lots of
>>Eh... This depends on the implementation. As I recall, Borland's Turbo
>>Prolog had predicates to which truths could be added and deleted,
> It's also nonstandard. And I haven't seen Turbo Prolog in
> far too many years to think about...
I saw it and I saw that it was good. ;) And standards are overrated
anyways... {double ;) }
> Actually, has anybody done any object-oriented parsing? I
Can you expand on this? I didn't follow...
Cheers,
J.
John Colagioia
[...]
> It occurs that there's a fundamental similarity to a rule-based
> language like prolog and, say, a database language; a query in prolog
> of the form 'is fact x true' basically means 'does there exist an
> entry in my table of rules for this fact', and 'for what values of x
> is this fact true?' is essentially a select operation. This always
> gets me wonderign if something like PL/SQL could be used for IF --
> obviously, the work involved in making this non-clunky would be
> tremendous, but it does bypass a lot of the things that make IF fit so
> ill-well in more mainstream languages; the weakness of static data
> declaration, the extremely lightweight object model, etc.
> Just a thought.
This is true. The major problem that I see with something like that
is reloading the entire database to restart the game. Because if you
don't, then you'll have a game that updates itself every time someone
plays it, which might appeal to some, but...
Hmmm...Object databases, perhaps? I haven't played with them much,
but an engine that understands OQL or something might be fairly neat.
Fraser Wilson
> I saw it [Turbo Prolog] and I saw that it was good. ;) And standards
> are overrated anyways... {double ;) }
I think you'll like Mercury (http://www.cs.mu.oz.au/research/mercury/).
It's a logic programming language, and it's fast, and sometimes it
reminds me of Turbo Prolog.
Of course, when I think of Turbo Prolog, I think of the advertisement
with BorlandMan coming to the rescue of somebody with an unspecified
(but definitely tricky) AI problem.
Fraser.
John Colagioia
> "John Colagioia" <JCola...@csi.com> writes:
>>Actually, has anybody done any object-oriented parsing? I
>>read an article not too long ago describing it as being
>>fairly nice, but didn't provide any useful implementation
>>details.
> Yes. I've found it useful for highly structured grammars
> (e.g. programming languages, particularly from the Algol family). If
> you have an EBNF, then you can pretty directly map named rules to
> classes, and choice-only rules map to inheritence. E.g. a Statement
> rule maps to a Statement class, and an If-statement maps to an
> If_Statement_Class, because it's one of the choices for the statement
> rule.
Any chance you could give me a quick example? I found some supposed
example code, but it was less than enlightening (and what I could
understand looked extremely clunky and inefficient).
> This sort of thing makes semantic analysis and code generation quite neat.
It sounds like it should be useful.
> I can't imagine that the limited IF grammar is particularly amenable
> to this sort of thing though. However, there's more than likely
> another way to apply it that I haven't thought of.
I'm thinking that the interest with respect to IF wouldn't so much be
in parsing "give the blue toy to the cat," but in allowing authors to
"patch in" experimental grammar additions like some that are being
discussed.
That, of course, depends on how it all actually works, though...
John Colagioia
[...]
>>I actually have some Prolog rules that I had to reorder
>>because--get this--the order in which I originally defined
>>them caused the engine to fall into an infinite loop.
> Yuck! And probably not very Dijkstra-like... But I see your point. Then
> again, infinite loops are no strangers to imperative languages... :)
Well, it wasn't so much the loop that annoyed me; it was the fact
that I couldn't *know* about the loop unless I understood the logic
engine, which I was never supposed to have to think about...
I mean, the nice thing about rule-based programming is really that
you don't have to worry about execution order, storage, or any of
those boring and error-prone things. Then along comes Prolog...
>>Regardless, though, a language with a slow runtime is only
>>going to be fast for smaller applications. Over a certain
>>size, and things go bad far too quickly.
> I see your point. But (and again, referring to Turbo Prolog), I once built
> an implementation of a (rather basic) conversation bot, that could even go
> back to previous subjects, and had a _ton_ of rules and it worked pretty
> fast. And we are talking about some 15 years ago, so...
It depends on the size. And, well, Turbo Prolog was so much better
than "standard" Prologs that I'd be tempted to not consider it Prolog
at all...
> I really believe that if your grammar is well specified, parsing should be
> a breeze for an arbitrary number of rules.
> For clarification, we are talking about parsing the player input, not
> parsing the game description language...
Parsing would be much easier, yes. Although I'd still rather see
someone work with something that's fixed Prolog's mistakes, like
Mercury.
There's also the question of how to get the parse results to the main
game engine, but that's not as difficult as it sounds, in general.
>>>>parsing. In particular, you really don't have anything
>>>>like persistent data (objects, for example), so lots of
>>>Eh... This depends on the implementation. As I recall, Borland's Turbo
>>>Prolog had predicates to which truths could be added and deleted,
>>It's also nonstandard. And I haven't seen Turbo Prolog in
>>far too many years to think about...
> I saw it and I saw that it was good. ;)
Yeah, I was actually in contact with David Intersimone, trying to get
him to dump Turbo Prolog onto the Borland Museum. Turns out there
are some major licensing issues.
> And standards are overrated
> anyways... {double ;) }
>
>>Actually, has anybody done any object-oriented parsing? I
> Can you expand on this? I didn't follow...
It's one of those things I've heard about, but never gotten to see in
working condition. Basically, each statement type has a class, and
the classes (as I understand it) "compete" to parse the incoming
statement, each aborting (and deallocating itself) as it fails. The
result of the parse is then a completed parse tree or sentence
diagram.
That seems to be conceptually similar to the standard Prolog
approach, but could be written in Inform or TADS without too much
trouble.
Heh...You now know what I know about the topic...
Joao Mendes
John Colagioia <JCola...@csi.com> wrote in
> Well, it wasn't so much the loop that annoyed me; it was the fact
> that I couldn't *know* about the loop unless I understood the logic
> engine, which I was never supposed to have to think about...
>
> I mean, the nice thing about rule-based programming is really that
> you don't have to worry about execution order, storage, or any of
> those boring and error-prone things. Then along comes Prolog...
Bah... I always thought of Prolog statements not so much as rules per se
but as a series of implicit-if-then statements... :)
Off-topic question: Does anyone have a clue as to why Lisp is more widely
regarded as the AI language of choice than Prolog or the later langs?
> Parsing would be much easier, yes. Although I'd still rather see
> someone work with something that's fixed Prolog's mistakes, like
> Mercury.
You know, if I wasn't sooooo drooling over TADS 3 right now, I'd take you
up on it... :)
> Yeah, I was actually in contact with David Intersimone, trying to get
> him to dump Turbo Prolog onto the Borland Museum. Turns out there
> are some major licensing issues.
A simple :( will suffice here, I believe...
> It's one of those things I've heard about, but never gotten to see in
> working condition. Basically, each statement type has a class, and
> the classes (as I understand it) "compete" to parse the incoming
> statement, each aborting (and deallocating itself) as it fails. The
> result of the parse is then a completed parse tree or sentence
> diagram.
Sounds like a powerfull concept...
Anyway. I'm going back to T3 now. That was a nice chat. :)
Cheers,
J.
Chris Kirkwood-Watts
| Off-topic question: Does anyone have a clue as to why Lisp is more widely
| regarded as the AI language of choice than Prolog or the later langs?
Maybe it has something to do with the fact that (Common) Lisp is a
_vastly_ more powerful language than Prolog...?
See Kaz Kylheku's recent message
<agno63$b1r$2...@luna.vcn.bc.ca>
which, admittedly, deals with C++ and data structures, but you should get
the point. It actually addresses the point that Lisp is the most widely
regarded language. Period.
Chris.
L. Ross Raszewski
>I mean, the nice thing about rule-based programming is really that
>you don't have to worry about execution order, storage, or any of
>those boring and error-prone things. Then along comes Prolog...
And then along comes Prolog (Pro-log)
And does it wanna give me IF and be my steady pick and let me do some
NLP (ee-ee)
Or maybe rather gather rules from all the :- and cuts I'd never do in
C (ee-ee)
When we met I was into Pascal,
Now my code can only be run by HAL
Sorry. Not nearly as good at this as some others. Appologies to The
Association *and* The Bloodhound Gang.
John Colagioia
[...]
>but as a series of implicit-if-then statements... :)
Well, you could do it that way, but you'll lose a lot
of the leverage that Prolog does actually provide.
>Off-topic question: Does anyone have a clue as to why Lisp is more widely
>regarded as the AI language of choice than Prolog or the later langs?
I get the impression that it has to do with the fact
that (a) LISP is far more flexible than Prolog, even
allowing "real work" (algorithms) to be done (though
they're not always necessary), and (b) since LISP
treats code and data equally, it's fairly easy to
write a program that builds some of its own logic
base, thus allowing a parser (for example) to add to
its own grammar, based on counterexamples.
Of course, the AI people I know all program in C and
PERL, for what that's worth...
>> Parsing would be much easier, yes. Although I'd still rather see
>> someone work with something that's fixed Prolog's mistakes, like
>> Mercury.
>You know, if I wasn't sooooo drooling over TADS 3 right now, I'd take you
>up on it... :)
It's not like you can't do both...
>> Yeah, I was actually in contact with David Intersimone, trying to get
>> him to dump Turbo Prolog onto the Borland Museum. Turns out there
>> are some major licensing issues.
>A simple :( will suffice here, I believe...
Heh. I figured it was implied.
[...]
>Anyway. I'm going back to T3 now. That was a nice chat. :)
Anytime. On- or off-list.
Fraser Wilson
> It's one of those things I've heard about, but never gotten to see in
> working condition. Basically, each statement type has a class, and
> the classes (as I understand it) "compete" to parse the incoming
> statement, each aborting (and deallocating itself) as it fails. The
> result of the parse is then a completed parse tree or sentence
> diagram.
This sounds similar to the way Dyer's parser worked, but the classes
are called demons (luckily it's not as widespread as BSD, so nobody's
become upset by that yet). There's a common lisp implementation at
<http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/nlp/nlu/mcdypar/lisp.tgz>.
Unfortunately, it appears to be the stripped down version from one of
the appendices of In Depth Understanding, but you can get the idea.
It's a bit overpowered for parsing commands in an IF context (it's
intended for understanding stories), and it returns a conceptual
dependency structure; an idea whose day has come and gone (imho). The
demons themselves are very low-level, and understanding sentences
where the key sections are separated by other words is a bit hacky. I
like the underlying concept though, and I've found that it is easily
adapted to use a class hierarchy to store meaning.
If you want to see a trace of the re-engineered version doing its
thing, let me know.
Fraser.
John
news:uptxpx...@FWILSON.i-did-not-set--mail-host-address--so-shoot-me...
That would be cool.
If the trace is small would you post it? Otherwise please send to my
de-spammed address.
Thanks
John.
John Colagioia
[...Dyer's parser...]
> <http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/areas/nlp/nlu/mcdypar/lisp.tgz>.
> Unfortunately, it appears to be the stripped down version from one of
> the appendices of In Depth Understanding, but you can get the idea.
Ooh! Thanks.
> It's a bit overpowered for parsing commands in an IF context (it's
> intended for understanding stories),
I don't know. I've considered an IF idea where the player can type
anything she likes at the prompt. If it's recognized as a command,
the PC does it. Otherwise, it's parsed as "informative," and can be
used at a later time, possibly adding more information when speaking
with NPCs.
[...]
> If you want to see a trace of the re-engineered version doing its
> thing, let me know.
Heh. As a general rule of thumb, I never decline additional
information. If it's too big to post, feel free to "clog" my e-mail.
David Thornley
John Colagioia <JCola...@csi.com> wrote:
>Joao Mendes <public...@anywhere.invalid> wrote:
>[...]
>>Bah... I always thought of Prolog statements not so much as rules per se
>>but as a series of implicit-if-then statements... :)
>
>Well, you could do it that way, but you'll lose a lot
>of the leverage that Prolog does actually provide.
>
any more), if you don't think of it that way you'll screw up. Prolog
is *not* programming in logic in any real sense.
>>Off-topic question: Does anyone have a clue as to why Lisp is more widely
>>regarded as the AI language of choice than Prolog or the later langs?
>
>I get the impression that it has to do with the fact
>that (a) LISP is far more flexible than Prolog, even
>allowing "real work" (algorithms) to be done (though
>they're not always necessary), and (b) since LISP
>treats code and data equally, it's fairly easy to
>write a program that builds some of its own logic
>base, thus allowing a parser (for example) to add to
>its own grammar, based on counterexamples.
>
The former is actually partly a function of the latter. In Common
Lisp (one of the two major modern dialects, the other being Scheme),
it's fairly easy to modify the language to add all sorts of new
things. If you don't like the object system that comes with it,
you can substitute another, without ever leaving the language.
This means that some sort of Lisp would be a very attractive choice
for somebody who wanted to do dynamic object definition or something
like that. The disadvantage, of course, is that free (as in beer)
Lisps do not exist for all popular platforms, and they differ among
themselves.
Now, I'm not saying that dynamic object definition would be in any way
easy to do, but it would be a whole lot less impossible in Lisp than
in other languages.
>Of course, the AI people I know all program in C and
>PERL, for what that's worth...
>
I can't imagine why. I'd expect worthwhile AI programs to be rather
large, and I wouldn't write a really large program in C or Perl if I
had other choices. C++, Java, or Common Lisp strike me as much better
choices, maybe even Python instead of Perl.
--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
John Colagioia
>In article <3d30301f$1...@excalibur.gbmtech.net>,
>John Colagioia <JCola...@csi.com> wrote:
>>Joao Mendes <public...@anywhere.invalid> wrote:
>>[...]
>>>Bah... I always thought of Prolog statements not so much as rules per se
>>>but as a series of implicit-if-then statements... :)
>>Well, you could do it that way, but you'll lose a lot
>>of the leverage that Prolog does actually provide.
>And, in my limited experience (limited because I didn't want to get
>any more), if you don't think of it that way you'll screw up. Prolog
>is *not* programming in logic in any real sense.
Hence my original comment about Prolog being vile and
I probably used the word "broken," at some point...
[...]
>>Of course, the AI people I know all program in C and
>>PERL, for what that's worth...
>I can't imagine why.
Same reason a lot of small-corporate code is in BASIC
and Pascal; the implementation was either free or
cheap when they started work, and the reference
material was easily available.
>I'd expect worthwhile AI programs to be rather
>large, and I wouldn't write a really large program in C or Perl if I
>had other choices. C++, Java, or Common Lisp strike me as much better
>choices, maybe even Python instead of Perl.
One thing I've learned in my time working with
computers: Implementation languages are rarely
chosen with the application domain in mind.
That is one of the things that makes this
community fairly unique and worth associating
with.
David Thornley
John Colagioia <JCola...@csi.com> wrote:
>thor...@visi.com (David Thornley) wrote:
>>In article <3d30301f$1...@excalibur.gbmtech.net>,
>>John Colagioia <JCola...@csi.com> wrote:
>>>Of course, the AI people I know all program in C and
>>>PERL, for what that's worth...
>>I can't imagine why.
>
>Same reason a lot of small-corporate code is in BASIC
>and Pascal; the implementation was either free or
>cheap when they started work, and the reference
>material was easily available.
>
For some time, there have been good Common Lisp implementations
freely for the more popular versions of Unix, and reference
material has generally been easily available. It may be that
the C and Perl was already installed, but a decent AI program
is usually sufficiently much work that it's worthwhile to put
a serious effort into tools.
>>I'd expect worthwhile AI programs to be rather
>>large, and I wouldn't write a really large program in C or Perl if I
>>had other choices. C++, Java, or Common Lisp strike me as much better
>>choices, maybe even Python instead of Perl.
>
>One thing I've learned in my time working with
>computers: Implementation languages are rarely
>chosen with the application domain in mind.
Yes, but if this is real AI it seems like an unusually large
mismatch. (Then again, I had a classmate in a pattern recognition
class that turned her homework in in Fortran.)
For real, serious AI it will be less work to learn and implement
Common Lisp than to do the work in C and Perl. Just as for real,
serious IF it will be less work to learn Inform/TADS 2/TADS 3/Hugo
rather than to program it in C++ or Java (as you hinted at in a
part of the post I deleted).
Joao Mendes
"John Colagioia" <JCola...@csi.com> wrote in
news:3d356ca2$1...@excalibur.gbmtech.net:
> Hence my original comment about Prolog being vile and
> I probably used the word "broken," at some point...
Bah... I still think Prolog is aesthetically perfect. ;)
Cheers,
J.
John Colagioia
>In article <3d356ca2$1...@excalibur.gbmtech.net>,
>John Colagioia <JCola...@csi.com> wrote:
>>Same reason a lot of small-corporate code is in BASIC
>>and Pascal; the implementation was either free or
>>cheap when they started work, and the reference
>>material was easily available.
>For some time, there have been good Common Lisp implementations
>freely for the more popular versions of Unix, and reference
>material has generally been easily available. It may be that
>the C and Perl was already installed, but a decent AI program
>is usually sufficiently much work that it's worthwhile to put
>a serious effort into tools.
I know that, and you know that, but you're overlooking the
driving forces of (particularly pre-everyone-on-the-
Internet) industry.
First, finding LISP is hard if you don't know LISP.
Related, wander down to your local book shop, and see if
there's still a copy of Steele's book; I haven't seen one
in many years. When the AI book has examples in C, guess
what the implementation language is going to be...
Second, and most importantly, no matter how bright the
person, people (especially research-y industry types)
absolutely hate scrapping code. Again, I'm guessing
that you're like me: time is budgetted into projects
for the explicit purpose of rewriting just about the
entire thing. Other people hate doing that, for some
reason, though.
Believe me, I've tried helping.
[...]
>>One thing I've learned in my time working with
>>computers: Implementation languages are rarely
>>chosen with the application domain in mind.
>Yes, but if this is real AI it seems like an unusually large
>mismatch. (Then again, I had a classmate in a pattern recognition
>class that turned her homework in in Fortran.)
I once had a student hand in a distributed database in
APL; *That* was fun to grade, and very, very
enlightening...
>For real, serious AI it will be less work to learn and implement
>Common Lisp than to do the work in C and Perl.
I'm going out on a limb, here, but I'm guessing you've
never had to make this argument at work. I ended up
leaving my last job because my coworkers wouldn't
accept just this concept. Code was written by
consultants, and we *certainly* weren't going to go
rewriting those couple-hundred lines of buggy crap...
..and besides "everyone" uses Java for low-level
database access and high-speed network
communications...
Oh, well...such is life, I suppose...
[...]
Fraser Wilson
> I don't know. I've considered an IF idea where the player can type
> anything she likes at the prompt. If it's recognized as a command,
> the PC does it. Otherwise, it's parsed as "informative," and can be
> used at a later time, possibly adding more information when speaking
> with NPCs.
One of my favourite bits from the classic Shrdlu trace was the bit
where Shrdlu doesn't know what a pyramid is, and the user types:
> A "steeple" is a stack which contains two green cubes and a pyramid.
OK
> Build one.
Wouldn't that be a fun thing to generalise?
> Heh. As a general rule of thumb, I never decline additional
> information. If it's too big to post, feel free to "clog" my e-mail.
A sample trace of the interaction with a tiny story and some questions
can be now sits at http://www.blancolioni.org/ada/audley/monty.trace.txt,
and annotations for the first bit are found at
http://www.blancolioni.org/ada/audley/annotated-trace.txt (they're not
hyperlinked or anything, sadly). More information is available here:
http://www.blancolioni.org/ada/audley
Fraser.
John Colagioia
Fraser Wilson wrote:
[...]
> A sample trace of the interaction with a tiny story and some questions
[...]