Message-ID: <3D2EC35E.4010704@csi.com>
Date: Fri, 12 Jul 2002 07:54:06 -0400
From: John Colagioia <JColagioia@csi.com>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc2) Gecko/20020618 Netscape/7.0b1
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: rec.arts.int-fiction
Subject: Re: Non-Imperative Parsing (was Re: Another worm for the NLP can...)
References: <Xns924645FEF5002joaomendesnetcabopt@194.65.14.150> <3d2ae2a2@excalibur.gbmtech.net> <Xns924861C153DDFjoaomendesnetcabopt@194.65.14.150> <3d2d7f33$1@excalibur.gbmtech.net> <Xns9248CD6247B0Fjoaomendesnetcabopt@194.65.14.150>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: ool-182f30fa.dyn.optonline.net
X-Original-NNTP-Posting-Host: ool-182f30fa.dyn.optonline.net
X-Trace: excalibur.gbmtech.net 1026474426 ool-182f30fa.dyn.optonline.net (12 Jul 2002 07:47:06 -0400)
Organization: ProNet USA Inc.
Lines: 71
X-Authenticated-User: jnc
Path: news.duke.edu!newsgate.duke.edu!nntp-out.monmouth.com!newspeer.monmouth.com!news-out.visi.com!hermes.visi.com!uunet!ash.uu.net!excalibur.gbmtech.net
Xref: news.duke.edu rec.arts.int-fiction:106076

Joao Mendes wrote:
[...]
>>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...

