From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: Inclusion of guile-log II Date: Tue, 03 Apr 2012 20:05:27 -0400 Message-ID: <87vclge4zc.fsf@netris.org> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1333498125 3188 80.91.229.3 (4 Apr 2012 00:08:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Apr 2012 00:08:45 +0000 (UTC) Cc: guile-devel To: Stefan Israelsson Tampe Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Apr 04 02:08:44 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SFDmF-0002ue-4d for guile-devel@m.gmane.org; Wed, 04 Apr 2012 02:08:43 +0200 Original-Received: from localhost ([::1]:47389 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFDmE-0008Oi-EI for guile-devel@m.gmane.org; Tue, 03 Apr 2012 20:08:42 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:57857) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFDmB-0008O7-A7 for guile-devel@gnu.org; Tue, 03 Apr 2012 20:08:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFDm8-0000aO-U9 for guile-devel@gnu.org; Tue, 03 Apr 2012 20:08:38 -0400 Original-Received: from world.peace.net ([96.39.62.75]:36821) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFDm8-0000ZX-Q6 for guile-devel@gnu.org; Tue, 03 Apr 2012 20:08:36 -0400 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1SFDlq-0004zk-MR; Tue, 03 Apr 2012 20:08:19 -0400 In-Reply-To: (Stefan Israelsson Tampe's message of "Tue, 3 Apr 2012 21:18:44 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:14207 Archived-At: Hi Stefan, Stefan Israelsson Tampe 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