guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

guile-prolog state at dec 22


From: Stefan Israelsson Tampe
Subject: guile-prolog state at dec 22
Date: Sun, 22 Dec 2013 15:05:08 +0100

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]