[DGD]parse_string

[Erlend M. Simonsen]

"Felix A. Croes" <felix at dworkin.nl> writes:

> The most useful and versatile solution is probably 2).  It can be
> done by adding several intermediate object finding rules:
> 
>     object_in_carried_container: object ?	find_in_container
>     object_in_room: object ?			find_in_room
>     object_in_living: object ?			find_in_living

I have added an object_in_container rule, and the sentence I try and
match look a something like this:
get OBJC from OBJ

The problem is that when the find_in_container() is called, nothing is
passed to the function describing which container to look for the
object in, only information about the object to find.  So, if I have
two conainers in the room, both holding a stone, how do I know which
of the two containers to get the stone from?

> More precisely: parsing happens left to right, but LPC functions are
> called in bottom-up right-to-left order.  It is not clear to me why
> this always picks the proper container.  Are you sure that this is
> actually the case?

I'm not sure that this _always_ is the case, but it has worked every
time I have tested it. In my get sentence above, first the OBJ is
found, and then the OBJC. 

> I don't fully understand the problem as you described it, but my
> guess is that the solution I gave above will work here too: add
> intermediate rules that differ only in the LPC function called.

I was a bit tired when I wrote this, so it might not have been 100%
clear. I'll try and clarify.

I have one big grammar containing all the rules and sentences for all
the verbs I have defined. Based on the matched sentence, I want to
call can_* and do_* functions to check that what the player is trying
to do is possible.

Since I don't know which sentence is matched, I try look at each
element in the result of parse_string() and generate a part of the
function name based on the type of each elelment. If the element is an 
object, I add an 'obj' part. If it is a monster of player, I add a
'liv' part. If it is a string, I add the string.

This means I get a function looking like this:

can_get_obj_from_obj()

But, this also means that I get a function looking like this when I
have a STR part in the sentence:

can_buy_beer_from_liv() and can_look_statue()

instead of

can_buy_str_from_liv() and can_look_str().

If I change it so that a string in the result adds 'str' and not the
string, I end up with

can_buy_str_str_liv() 

which in my opinion isn't exactly the desired result.

So, my question is how can I find out which sentence was matched so
that I can generate the correct functions( can_buy_str_from_liv)? Is
this possible at all? Or do I have to take a different approach to my
grammar and split it up, so that I have one grammar for each verb
rule, and not only one grammar containing everything?

I seem to remember that Jason Cone implemented a MudOS like parser
some time ago, and he had one object for each verb rule. Maybe I
should just follow his example, since then I would know which sentence 
it was that was matched, and can use the sentence to generate the
function names, not only the result from parse_string().

Thanks for the help so far, Felix.
-- 
Erlend M. Simonsen / Fairplay International AS
erlesimo at online.no / erlends at fairplay.no

List config page:  http://list.imaginary.com/mailman/listinfo/dgd