>> This is definitely something that's of interest to me. fine, then I know that it can be a useful library. But there need to be a discussion about an official interface or method to persist them and I hope that guile maintainers will chime in on this and enlight us.
> is it human-readable or just readable by guile? My format is readable and read in to guile via read > In addition it would be great for guile to be able to reason about the current state: e.g. walk the call stack and examine what's in it, or even change it. (Perhaps this is already possible, I > haven't checked.) i don't know about modifying the stack, but inspect ut is quite possible. Regards Stefan On Wed, Jan 27, 2016 at 9:51 AM, Andrew Gaylard <a.gayl...@gmail.com> wrote: > Hi Stefan, > > This is definitely something that's of interest to me. Closures are one > of the great strengths of scheme, and have been very useful to me in the > past. > > I'd love it for guile to have an "official" way to work with them, > including your load/save semantics. What's the format of the saved state? > — is it human-readable or just readable by guile? > > In addition it would be great for guile to be able to reason about the > current state: e.g. walk the call stack and examine what's in it, or even > change it. (Perhaps this is already possible, I haven't checked.) > > -- > Andrew > > > On 27/01/2016 10:13, Stefan Israelsson Tampe wrote: > > Hi all, > > In guile 2.1 the position of code segements are fixed relative certain > vectors and this makes it > possible to store indexes of code segements and as a possibility to > persist closures. I took advatage of this because state in guile-log means > that we must do exactly that. Persist not only datastructures like struct > lists and vectors vhashes etc, but also persist closures. So now one can do > cool things in guile-prolog like: > > prolog> X=1,stall,Y=2. > prolog> .setp 1 > prolog> .savep > prolog> .quit > > stis> guile-prolog > prolog> .loadp > prolog> .refp 1 > prolog> .cont > > X=1 > Y=2 > > prolog> > This is the interface: > --------------------------------------------------------------------- > (.setp ) <key> associate current state to key > (.refp ) <key> instate state referenced by key to current > state > (.savep ) save all referenced states to disk > (.loadp ) load new referenced states from disk > (.cont ) continue a stalled predicate from current > state > > I can make this persistant code into a library anyone interested? > > Oh the security implications of this is horrible but I don't pretend that > guile-log is secure so > I don't care. What's more demading is that it depends on groveling into > guile internal datastructures. Therefore I am reqesting an official way of > persisting closures. What's your take on that? Would you > guy's want to supply such a mechansim or is it bad practice? > > regards > Stefan > > >
