[DGD] segmentation fault during compile_object

[Jared Maddox]

> Date: Mon, 12 Aug 2013 23:06:33 +0200
> From: "Felix A. Croes" <felix at dworkin.nl>
> To: dgd at dworkin.nl
> Subject: Re: [DGD] segmentation fault during compile_object
> Message-ID: <E1V8zJx-0000Mo-Lj at pattern>
>
> bart at wotf.org wrote:
>> On another note, I am experiencing another oddity with the function
>> pointers
>> extension, this might be due to misunderstanding on my side, but it looks
>> odd
>> to me.
>>
>> Code like this does not compile (invalid argument 1 to kfun * (needs
>> function):
>>[...]
>> Well, maybe I should go back in hiding...  I really wasn't planning on
>> bug
>> hunting, but here is another one (sorry no patch this time) :-)
>>
>> On a default compile of 1.5 (latest updates from git), trying to compile
>> an
>> object that contains a line like:
>>
>> f = &create();
>>
>> causes the compiler to emit a syntax error (correct as CLOSURES is not
>> enabled) and then crashes the driver.
>
> That's what happens when you are basically the first user of this piece
> of code in 2 years :-)  The necessity of function pointers in LPC has been
> somewhat overstated.
>

I forget (or maybe I never looked), were they actually just
dispatch-by-name with a bit of window dressing? I half-remember
thinking that was all that should be needed to properly implement
function pointers in LPC: some decorations for dispatch-by-name, since
dispatch-by-name basically does most of what would be expected of
function pointers.


> Date: Mon, 12 Aug 2013 18:24:30 -0400
> From: "Littlefield, Tyler" <tyler at tysdomain.com>
> To: All about DGD and Hydra <dgd at dworkin.nl>
> Cc: All about DGD and Hydra <dgd at dworkin.nl>
> Subject: Re: [DGD] segmentation fault during compile_object
> Message-ID: <EF48D4F4-F72F-4973-8AFE-ABA7DF68D3DC at tysdomain.com>
> Content-Type: text/plain;	charset=us-ascii
>
> does this mean we will be seeing lambdas too? if events can take function
> pointers and you can easily extend stuff to use them as callbacks, lambdas
> would be really nice there as well.
>

> Date: Mon, 12 Aug 2013 15:29:12 -0700
> From: Raymond Jennings <shentino at gmail.com>
> To: All about DGD and Hydra <dgd at dworkin.nl>
> Subject: Re: [DGD] segmentation fault during compile_object
> Message-ID:
> 	<CAGDaZ_q0WNKXLs_c0P1EoGEGPNq5eKJbqBUX8W7GsDUdCMdOXA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> For the record, what is a lambda?
>

A lambda is the marriage of a function pointer and a copy of the
current runtime environment, stored in a single package, and called as
if it were a function. The amount of data stored varies, but the
defining example would be from a mathematical example:
 a( b, c ) = b + c
 d = build_lambda( +, 1 )
 d( 1 ) == 2
Mixed mappings would make the data storage pretty easy. A more
demanding (and powerful) variation is the continuation, which is
basically the result of storing a duplicate of the current stack
(including slightly modified instruction pointer) inside of a
variable. For those Unix gurus out there, it's like a fork() call that
stores the new process (including duplicate of the calling stack)
inside of a function pointer, instead of actually starting it.
Full-blown pure/strict functional languages would implement it by
(through whatever method) making copies of ALL data values and
function implementations that were directly or indirectly referenced
by the code that the lambda or continuation was being created from
(imperative implementations would, or course, have a more restrained
implementation).

Both are useful. I'd say that continuations are more useful, but
lambdas should be (much, much, much) easier to correctly implement (as
long as you set things up for them to be verified in response to
recompilation, anyways). Unfortunately, I think that both would
benefit from LWOs that aren't automatically updated, which I don't
recall being in DGD's feature set. Even more unfortunately,
continuations would either need some way to update the stack and
instruction pointer themselves, or somehow keep their original
blueprint around (the later of which could result in some blueprints
NEVER being destroyed after recompilation, an obvious flaw).


None of this is to say that I think either lambdas or continuations
are needed. If nothing else, continuations can be fully simulated with
a function pointer, mixed mapping and number in an LWO, and a switch
in the relevant function that uses the number to figure out where to
resume execution. Doing it like this also makes it more likely for the
implementer to actually think about the required conversions.