[DGD] happycode in DGD

[Jared Maddox]

> Date: Sat, 7 Sep 2013 14:57:03 +0200
> From: bart at wotf.org
> To: All about DGD and Hydra <dgd at dworkin.nl>
> Subject: Re: [DGD] happycode in DGD
> Message-ID: <20130907125651.M43356 at bartsplace.net>
> Content-Type: text/plain;	charset=iso-8859-1
>
> On Fri, 6 Sep 2013 16:55:49 -0700, Raymond Jennings wrote

> What this doesn't address is making such anonymous code run in the context
> of the function that defines them as would be needed for 'true' closures, BUT
>
> Actually, per statements from Wodan, the current maintainer of FluffOS (the
> maintained descendant of mudos), that isn't entirely needed to begin with
> since all local variables are actually passed to the closure and not
> actually shared, but object global variables are shared.

Technically, this isn't true... because all languages describe their
own details. So, as long as it meets the basic definition, it's all
gold. Still, this would be the easiest (and very possibly best)
option, and is one of the two that C++11 provides.

> To me that means a closure would on one side need to be its own object so
> they can survive recompiling the defining object, but they'd also need to live
> in the dataspace of the defining object.
>
> Sounds to me like it'd need some kind of halfway in-between LWO and
> heavyweight object.
>

I forget, do mappings stay shared after DGD finishes a particular
task? If not then a simple "mapping container" that overrides the []
operator would presumably do the job perfectly well.

If you feel like playing with the LPC compiler, then functions that
define closures could even use one to hold all of their data in the
first place, providing the same sort of closure as you get with
JavaScript.