[DGD] lambda operator re-re-visited?

[Carter Cheng]

Hello,

I have been giving some thought to adding some sort of lambda feature into
dgd and was wondering what some of the issues would be that would make such
an effort difficult. I have addressed in my preliminary brain storming some
of the issues that I thought would arise. If I were to proceed now I would
do so as follows-

1) rewrite the compiler to return more than 1 program per source. The
lambda function programs would be anonymous but have an existence
independent of the original program from which it came from. This is to
address the issue of persistence and recompilation when the lambda function
is pointed to by some object that is generated by another program and the
original program has been recompiled or destructed.

2) add a "source code" kfun with supporting data structures. I think memory
is cheap enough to consider this option and it has various benefits. Since
programs can usefully persist on dgd for extended periods of time in
general it might be nice to store the lpc source code with them to indicate
what they represent. Even if in general this isn't required since lambdas
can be passed around arbitrarily and have no names it might be nice for the
system to tell you what the lpc is originally.

3) initially don't support variable capture. This can be added later and
done in a similar manner as java with an implicit final keyword or like
fluffos where the variable is frozen when the lambda is created at runtime.

4) to support 3)- add a lambda opcode in the vm

5) to work with 2) add a couple kfuns one to read the source code field
from the lambda function and another to recompile it with different code. I
am not sure how best to get this to interact with situations where one
needs to intervene in compile objects.

6) use garbage collection on the lambdas to remove the programs when they
are no longer referenced.

I haven't completely studied the internals of dgd yet to see how difficult
this would be to do. I think the hardest part would be with the code
generation since the rest just recycles existing infrastructure. The code
generator and compiler only has one set of data structures currently for
one program and cannot do compiles within compiles which would be necessary
to support this. One at the very least  would need to generalize the data
structures to support multiple copies of a program inside the compiler as
it generates the lambda function code on the side.

As for syntax I am kind of partial to java/C++11 syntax but I am uncertain
how that would interact with the LALR(1) grammar so I would have to test it
out.

I am also unsure of how long it would take to do this and whether it is
worth the time. Any opinions? I am actually working on some other hobby
project on the side and I don
t want to take too much time away from it- but I would also like to give
back to the mudding community by contributing some code.

Best Regards,

Silenus.