[MUD-Dev] string parsing

[Chris Gray]

[Felix C:]

:I am writing the entire function as a server builtin, using lazy DFA
:construction, lazy DPDA construction, with the appropriate amount of
:caching between calls, etc.

Sorry, I don't grok the acronyms. (I've never been strong on theory, so
if they refer to something theoretical, I probably wouldn't understand
an explanation either!)

:In this case, `find_obj' should not just deal with "the rock", but with
:"the rock from the sack" as a single object.  I.e. it's a matter of
:adjusting the grammar.

You could do that. Sounds a wee bit hackish to me - you'll end up with
a mess of functions implementing all of the prepositions that you end up
wanting. At least the functions will know which preposition they are
dealing with, and can all call common lower-level routines to identify
the second noun phrase. Hmm. They might have to recursively call
parse_string to pull out that noun phrase. Gee, I guess that's why I
have a "ParseNounPhrase" builtin! :-)

:> My current system is less like your proposal than an earlier one I did.
:> I don't quite remember why I changed! I do recall, however, that I ended
:> up with a *lot* of rules in the grammar, to handle the various ways that
:> the player could give a command. I didn't do the lexical stuff, just the
:> syntactic level. The lexical stuff was hard-coded.
:
:Even if you don't remember <why> you changed, do you remember <what> you
:changed? :)

Urgh. Lemme go look - the old stuff is around here somewhere... ... found!
Its off in my "CPM" directory, which is stuff I saved from my CP/M machine
before I threw it away - that tells you how old it is! Anyway, it was
somewhat simpler than what you are planning - there was no structure to
grammar - each input form was flat, e.g. (from the docs):

    give [ARTICLE] ADJECTIVE* NOUN to [ARTICLE] ADJECTIVE* NOUN [PUNCTUATION]

The "word-types" were not pre-determined - this system required *all*
words used in a grammar to be in a central dictionary. That last could be
the main reason I didn't use that parser in my current MUD. Since the
sources are all there, I can go into more detail if needed. Basically, it
was part of a system I did called "Quest", which used curser addressing
to show a top-down view of a simple world using ASCII characters. There
were automatically maintained status displays, and the bottom half of
the terminal's screen was for a standard text I/O area. Single player only.
Oh yes, the rule for ambiguity was that the first grammar rule that matched
was the one that won, and the "first" relates to the order they were
defined in the grammar.

:My example does not really deal with this possibility at all.	It could
:be extended in several ways:
:- the function could return such an array, if the object was not found.
:- the function could return 0 indicating that this parsing is invalid;
:  this could be combined with an additional grammar rule that functions
:  as a catch-all for errors in the input.
:- assuming that the grammar is unambiguous, the function could deliver
:  feedback to the user at parsing time.

Generic errors from a top-level parser tend to be not very informative.
Such things as "syntax error" from the old-style yacc C parsers. I have
a couple in my parser, and I *really* don't like them. E.g. if you just
type 'give', it will respond:	Give who/what to who/what?    Ick!

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA