unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
* guile-prolog state at dec 22
@ 2013-12-22 14:05 Stefan Israelsson Tampe
  0 siblings, 0 replies; only message in thread
From: Stefan Israelsson Tampe @ 2013-12-22 14:05 UTC (permalink / raw)
  To: guile-devel, guile-user@gnu.org

[-- Attachment #1: Type: text/plain, Size: 2132 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2518 bytes --]

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2013-12-22 14:05 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-12-22 14:05 guile-prolog state at dec 22 Stefan Israelsson Tampe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).