[DGD]Foreach and anonymous functions in DGD: Take 2

Lee Randolph Salzman lsalzman+ at andrew.cmu.edu
Tue Jan 30 03:40:47 CET 2001


Grr... I don't seem to be having must luck with mailing lists lately, but anyway:

Felix A. Croes wrote:

Okay, most everything has been fixed, I believe.
http://www.lvdi.net/~lee.salzman/dgd-mod.tar.gz
http://www.lvdi.net/~lee.salzman/dgd-mod.diff.gz
(same place)

>Some comments on the state of that code:
>
> - You left some debugging code in mud/kernel/sys/userd.c.
Gone now.
> - Fairly pointless changes to mud.dgd, src/Makefile and src/alloc.c.  A
>   number of whitespace-only changes in code elsewhere; you'll want to
>   remove these since they will only make tracking the vanilla driver
>   source more difficult.
These were unintentional from debugging code and such. Gone now as well.
> - src/comp/pool.c and src/comp/pool.h are not in the diffs.
There now. :)
> - evaluate() doesn't seem to be checking if the object in which the
>   anonymous function is defined still exists.
Added code to check if the owner of the closure actually exists.
Not quite sure if it is correct.
> - Should function_name() and function_owner() really exist?  The latter
>   even assumes that the owner is a string, rather than an object.
function_name () has been removed as it reveals odd internal details of
the implementation, anyway. function_owner () was fixed (I seemed to
have
stopped in the middle of a cut n' paste without finishing on it before)

which is a useful operation. It was intended that function_owner ()
return an object, but it did not for aforementioned reason.

>I didn't see a nil check on the array or mapping.  Since you generate
>LPC code with calls to kernel functions, you should add such a check,
>or people will get errors like "bad argument 1 for sizeof" instead.
Added a runtime check that will throw an error if the arguments are not
of the correct type.

>You can stick to unique function names, as long as they are
>unique within the object, and not callable with call_other().
>But it's better to make them private and call them with i_funcall() 
>rather than i_call().  You can keep the current naming scheme if
>you like, those names just wouldn't be used in calls anymore.
Changed the specifier on a closure to C_STATIC. function_exists()
will allow you to create a closure with the function so long as the
creating object is actually the one on which it exists. I also
moved to a better naming scheme for closures, essentially:
\foo at bar where foo is the index of the closure as it occurred
in the source file and bar is the file name in which it occurred.
This should ensure closure names are globally unique. i_call()
is still used as there is no real justification for duplicating
its functionality. 
   I was tempted to add a C_ANONYMOUS attribute to functions that
prevents them from being the target of a call_other, but otherwise
haves them behave as public functions so the owner could not call
closures via a call_other, however, there seems to be no more bits
left for this attribute. So for now, I just left closures with
C_STATIC. A klugey solution could have been to check if the
function's name starts with '\\', but I decided against it. :)

>In DGD's typechecking modes 1 and 2, no return type normally means
>`void'.
If a closure is created with no return type, it is now assumed to have
a return type of void.
ex: \(){} now has an assumed return type of void.

Also, just because I felt like it, I added a curry() function that
allows you to create a new closure with implicit arguments.
ex:
evaluate(curry(\string(string x, string y) { return x + y; }, "foo "),
         "bar")
=> "foo bar"
curry() does not modify the closure passed to it but instead returns
a new closure. curry() can be repeatedly used upon a closure and as
expected curry (foo, bar, baz) is isomorphic to
curry (curry (foo, bar), baz).

                                    Lee Salzman

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



More information about the DGD mailing list