This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [bug #14098] runnable rfe


 > Thanks.  I checked in this patch, with a few minor changes.
 > 
 > I didn't include the setIndirectDefines flag.  You say it is
 > "closer" to 1.7 - but I don't think that was right.
 > 
 > We could add an optional 'shared' flag to the runnable function, just like
 > the scheme-window function takes, but I don't think it should be the default.
 >  Also, I'm not convinced it's needed at all.  If you disagree, perhaps you
 > could post some use-cases on the mailing list so people can discuss it.
 > 

Fair enough. Certainly in some cases locations could be used to share 
state between the closure and the main environment. However, I rely
on shared bindings as I never interact directly with the main
environment -- I use SSL repls (like TelnetRepl) to interact with kawa. 
These repls run as futures, and I want each of them to see and modify the 
same bindings. A shared flag would be a reasonable way to specify 
this behavior.

The claim that the behavior with setIndirectDefines was closer to 
that in 1.7 meant that it allowed bindings to be consistently shared
among futures and the main environment. 

(background for list -- the patch mentioned here moves most of the 
functionality of gnu.mapping.Future into gnu.mapping.RunnableClosure.
The latter allows a procedure to be passed as a Runnable along with 
its environment.  In the patch I attempted to slip in another change 
which makes shared bindings the default, as in 1.7)

thanks for putting in these changes.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]