From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Israelsson Tampe Newsgroups: gmane.lisp.guile.user,gmane.lisp.guile.devel Subject: guile-prolog state at dec 22 Date: Sun, 22 Dec 2013 15:05:08 +0100 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bb05000bafe9404ee1fff70 X-Trace: ger.gmane.org 1387721138 13834 80.91.229.3 (22 Dec 2013 14:05:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Dec 2013 14:05:38 +0000 (UTC) To: guile-devel , "guile-user@gnu.org" Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Dec 22 15:05:43 2013 Return-path: Envelope-to: guile-user@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 1Vujf5-0003JX-I1 for guile-user@m.gmane.org; Sun, 22 Dec 2013 15:05:43 +0100 Original-Received: from localhost ([::1]:57949 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vujf5-0002fa-2S for guile-user@m.gmane.org; Sun, 22 Dec 2013 09:05:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VujeZ-0002KD-VI for guile-user@gnu.org; Sun, 22 Dec 2013 09:05:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VujeY-0006QQ-Lh for guile-user@gnu.org; Sun, 22 Dec 2013 09:05:11 -0500 Original-Received: from mail-pd0-x231.google.com ([2607:f8b0:400e:c02::231]:62290) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VujeY-0006QM-Ar; Sun, 22 Dec 2013 09:05:10 -0500 Original-Received: by mail-pd0-f177.google.com with SMTP id q10so4229397pdj.8 for ; Sun, 22 Dec 2013 06:05:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=o4+CJflr7mlOnZDfC1jVr/+i2tQoZIAWO9zfjZPDFiE=; b=yhz3JDhwNYe3KMaoEgNTcCvs4VjJF9lHx6F14qqQu9Ce/tegFA7vuLOYYhaQyMs0Tk 3hJ3VWY9x/TU31seV1IZ2FSeDKYg3mkDeijVpDsQReXRZilf6btRTY/tx1MwWFzsOBZp p9BttBkLi/E1+0f4UTxLyl2VTwof24ja97tKHJ+YivCE2xeq3x4fF72+XM4qJwmgf0Rn YyfczOezL2Fs3AnY2UUeglSKcbTqqdePId/KmkK7phpHP4UvLCd2WWjd0d+U4TIgyPXa ZYm6uuRRoFuE3vkjEvs7Bb+QVZ/u2cSAoKzx7XdLFL5qjPMNPQ2y6ZX6QpPSDs6pfcu7 Pnvw== X-Received: by 10.66.170.138 with SMTP id am10mr20428970pac.51.1387721108682; Sun, 22 Dec 2013 06:05:08 -0800 (PST) Original-Received: by 10.70.91.133 with HTTP; Sun, 22 Dec 2013 06:05:08 -0800 (PST) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c02::231 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:10938 gmane.lisp.guile.devel:16786 Archived-At: --047d7bb05000bafe9404ee1fff70 Content-Type: text/plain; charset=ISO-8859-1 Heya folks, The effort of getting prolog onto guile is closing in. There still remain some work but the difficult parts have been implemented. One huge issue is to be able to take advantage of modules. I first did think that we should have both symbols as in scheme symbols and functions as in normal functions and a item naming a function is scoped under the module and and the symbols are not. It can be done, but the cost is that quite a lot of porting is needed to get normal prolog programs to run under guile-log, So now there will not be any notion of symbols in prolog everything is functions and are scoped under the module. This will mean that combining kanren and prolog will be a bit of pain because every symbol used must be transformed to a variable and then, like in CL, need to be exported to the user. Perhaps we can extend prolog to allow scheme symbols . Also I will punt on iso-prolog character handling because unicode is more preferable. I also punted on having different function objects for different arity, This can be an issue when porting prolog programs. There remains to get more up to spec file handling (basics work) and a few funcitons implemented, then the interface will be ready. I will also look up open libraries for prolog and start working my way through them to test out the prolog engine and also setup a repo that can be downloaded, e.g. any twarts in the port fixed, so that what people expect to have working in prolog is there. One issue I have is that compilation time is really long and will be an issue for large prolog programs. The parser is fast enough but compiling to bytecode takes a really long time. I plan to try to fix this by changing matcher to a functional interface in stead of a macro that expands to long code segments, this matcher, if implemented in C, would probably be as fast as the macro expanded code for bytecode based guile, later when we get native the compile times will get shorter and then also perhaps we can move over to a macro again. This work will be for after a release. It's green outside, but still, a happy Christmas to you all! /Stefan --047d7bb05000bafe9404ee1fff70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Heya folks,

The effort of getting= prolog onto guile is closing in. There still remain some work but the
difficult parts have been implemented.

One huge issue is to be able to take advantage of modules. I fir= st did think that we should have both symbols as in scheme symbols and func= tions as in normal functions and a item naming a function is scoped under t= he module and and the symbols are not. It can be done, but the cost is that= quite a lot of porting is needed to get normal prolog programs to run unde= r guile-log, So now there will not be any notion of symbols in prolog every= thing is functions and are scoped under the module. This will mean that com= bining kanren and prolog will be a bit of pain because every symbol used mu= st be transformed to a variable and then, like in CL, need to be exported t= o the user. Perhaps we can extend prolog to allow scheme=A0
symbols .

Also I will punt = on iso-prolog character handling because unicode is more preferable.
<= div style>
I also punted on having different function o= bjects for different arity, This can be an issue when porting prolog progra= ms.

There remains to get more up to spec file h= andling (basics work) and a few funcitons implemented, then the interface w= ill be ready.

I will also look up open= libraries for prolog and start working my way through them to test out the= prolog engine and also setup a repo that can be downloaded, e.g. any twart= s in the port fixed, so that what people expect to have working in prolog i= s there.

One issue I have is that compilation time i= s really long and will be an issue for large prolog programs. The parser is= fast enough but compiling to bytecode takes a really long time. I plan to = try to fix this by changing matcher to a functional interface in stead of a= macro that expands to long code segments, this matcher, if implemented in = C, would probably be as fast as the=A0
macro expanded code for bytecode based guile, later when we get = native the compile times will get shorter and then also perhaps we can move= over to a macro again. This work will be for after a release.

It's green outside, but still, =A0a happy Christma= s to you all!
/Stefan
--047d7bb05000bafe9404ee1fff70--