Hi all, I wanted to describe what my nearest effort in the guile-log world will be targeted at.
First a small discussion of guile-log. Guile-log is a macro system that originally was developed in order to have a more schemish macro system to model prolog program in. Kanren does not work here because of it's lack of cut. Then with the system getting an efficient continuation like feature for the stack the intereaving part of kanren could be implemented and in guile-log there is an almost complete kanren interface implemented ontop of guile-log. Then ontop of this is the possibility to use traditionally stack based prolog like variables as well as kanren like variables mixed or by itself (kanren varaibale bindings sits on a functional assoc like structure passed with the calculation). This combo is strictly more featureful in one sense because with this we can have both dynwind like features and kanren like features. To implement the interleaving part of kanren we used a kind of variables which state was kept across unwind/rewind and could at will store it's state so that it could later be retrieved. It was dog slow though and added a quite significant overhead to the interleaving operations. So now I'm in the process to speed that system up, and the current state is that I have it partly working. What's remaining? Well it boils down to this. In order for the interleaving operations to work I need to reinstate and save parts of the stack multiple times. Although this could be mitigated to quite low overhead if we only use the kanren like variables, the standard stack solution is not too bad either because we assumed that the objects putting onto the stack and back on a tree structure was not mutating and hence storage allocation could be reused and almost no consing is needed. But with the new system different versions of the objects will be needed and this could invalidate the tree structure in subtle and inefficient ways. The solution to this is to maintain a separate stack structure for only these mutating objects with the logic that we will do basically full copying when needed. So this is what's next with guile-log to implement the mutating stack. A new feature that will be added to this is real fluid-like objects. Previously fluid-set! was not supported. And also an old feature that was bitrotted will be restored e.g. the possibility to do breadth like search algorithm via storage of state e.g. the code in postpone.scm. If you are curious about guile-log you may find it at https://gitorious.org/gule-log I do have some doc's in there and there are also some simple makefiles to compile the nessesary C code. Probably you will need to murk the Makefiles but's it's a no-jobb for a hacker :-) Beware the state of that repo is a bit in fluid right now. Comments are welcome. /Stefan
