[DGD] lambda operator re-re-visited?

[Carter Cheng]

My thought on this is to not recompile L when A is recompiled since lambda
operators are runtime operators and should have the illusion of creating
the function on the spot. As for outdate variables this shouldn't happen
since like C/Java the capture should happen when the lambda is invoked and
be fixed (the alternative is to have heap frames which well seems like a
lot of work for not much gain since you can also refer the local variables
a long with fields in the object). Recompiling L should be handled by a
special mechanism like a kfun with proper inspection i.e. reporting as a
string what the code was initially and what variables are captured and
their current constant values.

On Tue, Jan 3, 2017 at 1:55 AM, Felix A. Croes <felix at dworkin.nl> wrote:

> Carter Cheng <cartercheng at gmail.com> wrote:
>
> > 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.
>
> How do you propose to handle the case where an object with defines an
> anonymous function is recompiled?  Specifically the following scenario:
>
> Object A exports an anonymous function, which we will refer to as L.
> Object B has a reference to L.
> Object A is recompiled.
>
> If L is not also recompiled, then it could refer to outdated functions
> and variables in A.  But since it is anonymous, it cannot be determined
> which new code should be used for L.
>
> Regards,
> Felix Croes
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd