guile-log getting a new stack

[Stefan Israelsson Tampe <stefan.itampe@gmail.com>]

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