[DGD] Working with parse_string()

[Kamil N]

2009/7/24 Felix A. Croes <felix at dworkin.nl>:
> However, at this point I think it may be best to handle this problem in
> LPC.  At the grammar level, it's always going to look as "give word word
> word word word..." without a grammatical way to determine where OBJI
> ends and where LIV starts (unless you can determine case at the token
> level).  So I'd change the grammar to

Thats one of solutions I've been thinking of too. But then I loose
some advantages of parse_string and also makes processing less clean.
As I want to use verb system that was discussed alot on this list (one
file per verb, inheriting verb ob, this object describes what parse
rules apply to it, then some central parse_d collects it all and
parses every user input through this collected ruleset), it could
cause a little mess.

So far I'm quite successful with the idea I posted in previous mail -
I do parse_string(..., ..., MAX) where MAX = 3..6 (still checking what
number is the best for my purposes, seems like 3-4, usualy doesn't
return more than this). Every find_* function adds last element to
every object it found, which is integer saying what detail level was
used to find certain object (1 for just noun, 2 for adj noun, 3 for
adj adj noun, 4 for ordinal adj adj noun etc.). Then I have array of
parse tree results like:

({
    ({ "give", ({ OBJ("sharp sword"), 2 }), ({ OBJ("stinky foul
goblin"), 3 }) }),
    ({ "give", ({ }), ({ }) }),
    ({ "give", ({ OBJ("sharp sword"), 2 }), ({ OBJ("foul goblin"), 2 }) })
})

(actually I wonder if it would be possible to put a mapping there
instead of array, so I have OBJ("sharp sword"): 2, but I think it can
cause problems when returning from LPC funcs called by prase_string,
think they force mixed *array there..)

I discard first column because for verbs it will always be the same,
then I iterate over every parse result and sum provided detail levels
to array int *weights (its index is same as index of parse tree
result). This will give me:

({
    5,
    0,
    4
})

After this its just finding biggest number in this array and returning
proper arguments to do_<verb> function. I still need to think how to
calculate weights for more complex results - for example LIV token
returning array of OBJs instead of single OBJ, but I think thats just
a matter of doing some examples and monitoring the results.

Nice thing is that phrases that are correct resolve to proper objects
immediately (in one parse iteration), only these where phrases are
mistyped or objects don't exist take more iterations. Now question to
Felix - should I worry about the "cost" of such operation, assuming I
won't allow last parse_string argument to be higher than 5? Servers
are nowdays quite powerful, much powerful than at the times when DGD
was first released, so I wonder if I should even worry about
performance issue at this stage, or I should concentrate on making
things work without overoptimizing?

After doing some code that had to run through arrays etc. I started
wondering - why there are no functions like sort_array in DGD and
similar ones that make data manipulations less painful - I tried to
find info about this on lists but couldnt find anything. Should I
write these functions myself? If so, where to add them? I read that I
shouldnt put everything in AUTO object because any change there means
recompiling every single object that exists on the mud. I must admit
it feels a bit strange not to have all the functions I knew from other
LpMuds, does it mean its ok to add them myself, and where its best to
do it? I always throught all "low level" functions like those used to
manipulate basic data types should be coded in the driver because of C
speed and stuff like that :) Does it mean DGD is so quick I can as
well code them in LPC and it will be fine, even with functions that
are going to be used very often in the code?

 I also found some weird behaviour I havent noticed before:

1) allocate(n) was once filling array with zeros, now its nill - are
there any plans to change it behaviour so for example it fills array
with empty values of this array's type, for example for string *arr
its "", for int *arr its 0 etc. Or maybe just adding different
function doing this?

2) I tried to find kfun m_delete, but only found that I should set
value of given mapping key to 0 to remove it - it doesn't seem clear
to me, what happens if I want to actually store this information:
mapp[key] = 0 instead of removing key element completly? Having
mapping value set to 0 and not having that element at all are not the
same things in my eyes :) Maybe I just got it wrong, will be grateful
if someone can clear this for me :)

Thanks,
KN