[DGD] Working with parse_string()

[Mikael Lind]

2009/7/24 Kamil N <kamiln at gmail.com>:
> ({
>    ({ "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..)

Just return ({ ([  OBJ("sharp sword"): 2 ]) }) instead of ({ ({
OBJ("sharp sword"), 2 }) }) from your parse function if you want a
mapping. Parse functions can return arbitrary types and reshape the
parse tree. Only the outermost value must be an array for a successful
parse, or nil for parse failure.

> 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?

The general rule is to make something work before you make it fast.
Some say that the performance improvement from non-working to working
code is infinite, which would make it the ultimate optimization.

> 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?

DGD is minimalist. You should be able to find plenty of sort_array()
implementations in LPC. It's up to you if you put everything in the
auto object or use some kind of utility lib scheme. DGD also allows
you to precompile LPC code into C code.

IIRC, DGD sorts the return value of map_indices(). You can use this to
sort strings, ints, or floats.

>  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?

See kfuns allocate_int() and allocate_float().

> 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 :)

If nil is enabled, it replaces 0 as the deleted value for mappings.

Use map[key] = ({ value }) instead of map[key] = value if you want to
be able to store nil values in a mapping.

-- 
Mikael Lind
http://elemel.github.com/