[DGD] happycode in DGD

[Raymond Jennings]

Should probably admit up front that this is all based on what little I know
about DGD internals.  I don't (yet) know how to tweak the parser to
recognize happycode, or how to tweak the vm to dispatch.

My post here about my game plan was mostly to see if anyone in the know
could pick flaws in my plans.  The feedback I got was helpful.

Actual implemetnation will be more difficult and I have some learning to do
first, but it's definitely a start.


On Sun, Sep 8, 2013 at 4:01 PM, <bart at wotf.org> wrote:

> On Sun, 8 Sep 2013 17:30:38 -0500, Jared Maddox wrote
> > > 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.
>
> Well, its more a matter of what the goal of such would be to begin with. If
> that is to provide easier porting to dgd for current mudos/fluffos based
> mudlibs then what those do define the details initially.
>
> >
> > > 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?
>
> Not when passed to a different object.
>
> > If not then a simple "mapping container" that overrides the []
> > operator would presumably do the job perfectly well.
>
> Not when passed to a different object, your container will be an lwo if you
> want the operator override, and won't stay shared after the task finishes.
> Make it a real object, and you wont have this problem, but you won't have
> operator overloading, and will need to explicitly get rid of it when its no
> longer referenced by anyone.
>
> As long as things stay within the same object, its all fine.
>
> Bart.
> --
> http://www.flickr.com/photos/mrobjective/
> http://www.om-d.org/
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>