[DGD] lambda operator re-re-visited?

[bart at wotf.org]

Anything I can think of to maintain consistency comes down to always assuming
they changed, and any closures being defined by the previous compile becoming
invalid. Adapting code to deal with that however seems like a lot more work
then what one has to do for avoiding the need for anonymous functions.

I can think of a number of more complex schemes that could preserve those
anonymous functions that didn't change properly in many cases, but it merely
takes a few seconds of thought to come up with situations in which those will
assume a function did not change, while in fact it did (ie: you indicently
happen to use the same string of code for a new anon function used from
different places in the same object).

relying on line numbers: as pointed out by previous posters, those are bound
to change.

relying on code: this does not uniquely identify an anonymous function.

relying on the name of the defining function and the code for the anonymous
function seems the best candidate, but can be made to fail as soon as a
function defines multiple anonymous functions.

So... assuming all of them become invalid seems like the only way to produce a
consistent and predictable result, but that means all consumers of an
anonymous function must now count on it becoming invalid and having to obtain
a new pointer... 

Just writing a non anonymous function and passing the function pointer
(closures extension) or the combination of object reference and function name
(and possible default arguments, similar to what for example Gurbalib's menu
system does), seem to be a far less painful way to go.

In-place recompilation must absolutely be predictable and reliable to prevent
introducing inconsistencies in interfaces and internal data. That applies both
to the driver and lpc side of things (ie, you need good upgrade handling of
your data, but also the driver must behave in a consistent and predictable way). 

I've had to restart the universe of Way of the Force after 5 years of 'virtual
uptime' at some point to deal with an inconsistency which probably had been
there for years, and which would have been extremely difficult to deal with at
runtime, not to mention, who's gonna tell the case I did notice was the only
case. When aiming at a persistent game, one simply cannot afford such things,
and the amount of effort needed to correct such a situation is going to dwarf
the time savings of not having to write named helper functions (which covers
like 99%+ of all use of anonymous functions in any lpmud lib that has them)

The idea of supporting mudos/fluffos like lambdas (happycode) seems good at
first glance, when aiming at porting libs made for those drivers to dgd.
However, I think that is:
1. a decade too late really
2. not going to take much advantage of what makes dgd interesting, actually
the opposite.

I'll refer to a recent discussion on the dgd channel concerning reflection for
example. A use case that was presented for reflection is the way in which for
example the Dead Souls mudlib saves its inventories. While the use case makes
perfect sense when save_object and write_file are all you have, it really
makes no sense at all when you have a persistent environment that can take
care of the exact same thing in a simpler and more reliable way. Accordingly,
time spent on modifying such a mudlib to take advantage of persistency is much
much better spent then time spent on modifying DGD to support approaches that
DGD wasn't conceived for.

So, considering this, I'd really not invest any time in either mudos alike
lambdas, or reflection, or anything else where the motivation is to make
porting of foreign mudlibs easier.

Instead, I'd put time in things like extending hashing and crypto support,
possibly providing an interface to openssl, zlib, or for example an idea that
Quixadhal mentioned, an interface to an image library allowing one to read for
example jpeg, png etc files without having to do the decoding and
decompression in lpc.

I'm myself pondering doing some work on the network extensions to better
integrate the code with the current comms/connection code, and make it support
ipv6 properly, but kinda wondering if I should bother seeing how dgd without
network extensions can do almost everything I want, with the exception of
opening a random port (which I use for node to node links in a distributed
system) and getting me the underlying error when a connection fails, both can
be worked around relatively easily.

Bart.

On Sat, 7 Jan 2017 08:45:31 +0800, Carter Cheng wrote
> Do you have a better suggestion?
> 
> On Sat, Jan 7, 2017 at 2:19 AM, Raymond Jennings 
> <shentino at gmail.com> wrote:
> 
> > Please please please oh please do not use line numbers as discriminants.
> >
> > Source code is VERY mutable, and even a reformatting can change things.
> >
> > On Thu, Jan 5, 2017 at 3:53 AM, Carter Cheng <cartercheng at gmail.com>
> > wrote:
> >
> > > Actually I do not see it as that heuristical once the discriminant is
> > added
> > > the identifier is unique. Also basically programs are identified by file
> > > name in the common case already. So you would have something like
> > > filename#line number.discriminant for a given program and any object
> > would
> > > include the additional object number.. The discriminant is to
> > differentiate
> > > between two "closures" originating from the same line.
> > >
> > >
> > >
> > > On Thu, Jan 5, 2017 at 5:03 PM, Felix A. Croes <felix at dworkin.nl> wrote:
> > >
> > > > Carter Cheng <cartercheng at gmail.com> wrote:
> > > >
> > > > > I think breaking the anonymity a bit for the purposes of
> > recompilation
> > > > > might be a possible solution. I.e. associating something like a file
> > > path
> > > > > and line number with some extra discriminant to each closure's
> > metadata
> > > > and
> > > > > having a way to locate the anonymous functions associated with a
> > given
> > > > > piece of source.
> > > >
> > > > Giving up the anonymity would be a solution, but what you are proposing
> > > > is just a heuristic.  I doubt that it will be so easy.  It would be no
> > > > good if a failing testcase can be constructed for it.
> > > >
> > > > Regards,
> > > > Felix Croes
> > > > ____________________________________________
> > > > https://mail.dworkin.nl/mailman/listinfo/dgd
> > > >
> > > ____________________________________________
> > > https://mail.dworkin.nl/mailman/listinfo/dgd
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> >
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd


--
http://www.flickr.com/photos/mrobjective/
http://www.om-d.org/