[DGD] lambda operator re-re-visited?

[Carter Cheng]

I am not entirely sure what you are asking. Are you asking about the
behavior of lambda in general or something to do with the fluffos
implementation of it?

For fluffos one still has a standard $() operator which captures the
contents of an expression in the existing context and turns it into a
constant inside the closure.


On Wed, Jan 4, 2017 at 1:30 AM, Raymond Jennings <shentino at gmail.com> wrote:

> Can lambdas or happyclosures attach to object local variables, or only
> function scoped local variables?  The difference seems to be important at
> least to elaborate on.
>
> On Tue, Jan 3, 2017 at 8:46 AM, Carter Cheng <cartercheng at gmail.com>
> wrote:
>
> > 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
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd