Re: Inclusion of guile-log II

[Mark H Weaver <mhw@netris.org>]

Hi Stefan,

Stefan Israelsson Tampe <stefan.itampe@gmail.com> writes:
> The guile-log code is very dependent on guile! It's based on a c-file
> which uses
> guile C interface in order to get speedy and featureful at the same
> time. So basically I have no hope that this codebase could be
> independent from guile.

Several libraries for Guile (e.g. guile-gnome) include C code that uses
Guile's C interface, and this does not pose any difficulties for making
it an external package.  Can you please explain more clearly why
guile-log is impractical to package separately?

FWIW, I find guile-log to be very interesting work, but I also get the
impression that it is a somewhat experimental and unproven approach to
logic programming in Scheme.  Only time will tell whether it proves to
be a successful approach.

One of my concerns is the extensive use of mutable state in guile-log.
Recently I have been thinking about how best to support scalable
lock-free concurrency in Guile, so this question looms large in my mind:
How effectively will guile-log be able to make use of a potentially
large number of processor cores.  Do you have any thoughts on that?

It's unclear whether individual processors can be made much faster than
they are today.  Making efficient use of a large number of processors
will likely become increasingly important in the future.  In that
context, there is a significant advantage to avoiding mutation of shared
state, since that causes cache lines to bounce back and forth between
processors, which kills performance.

Kanren is written in a purely functional style, and this may well prove
to a significant performance advantage in the multi-core future, even
though it runs slower on a uniprocessor.

    Regards,
      Mark