Re: using module as fact store

Wow, the difference on current_predicate call you show me is hopeful, I didn't notice this. Cannot wait to try next morning. :)

  

 ------------------ Original ------------------
  From:  "Paulo Moura";<[email protected]>;
 Date:  Wed, Jan 15, 2014 00:57 AM
 To:  "SWI-Prolog"<[email protected]>; 
 
 Subject:  Re: [SWIPL] using module as fact store

 


On 14/01/2014, at 16:40, Lumj <[email protected]> wrote:

> Hi, I've come to a situation where the data my application is processing is in unit of database. For example, I want to transform a world into another, where both worlds are described in the form of a database.

How much typically changes in those transformations?

> Naturally the first approach I thought about is simply using dynamic modules to represent databases, but soon I find:
> Enumerating facts is troublesome(especially in my application the fact types supported may not be statically determined)--I have to use stuff like current_predicate and clause, and the fatal thing is that, current_predicate may enumerate predicates not defined by my application(system predicates that may be autoloaded), thus makes this approach less attractive.

That depends on how you call current_predicate/1. A simple example illustrating the differences:

?- assertz(m:foo(1)).
true.

?- assertz(m:foo(2)).
true.

?- assertz(m:foo(3)).
true.

?- current_predicate(m:P).
P = foo/1 ;
false.

?- m:current_predicate(P).
P = foo/1 ;
P = portray/1 ;
P = file_search_path/2 ;
P = term_expansion/4 ;
P = ansi_format/3 ;
P = prolog_file_type/2 ;
P = (multifile)/1 
...

> Is the module system in SWI prolog suitable for this situation?

You could also use Logtalk objects but modules should be slightly more efficient.

> PS: The way I'm taking now(mainly to temporarily work around this) is refactoring w:f(x) into w:fact(f(x)), and then do w:fact(F) to get all facts. This is quite clean and straight to my expection but it introduces a meta layer.

And that meta-layer also hurst indexing and thus performance. Better avoided if possible.

Cheers,

Paulo

-----------------------------------------------------------------
Paulo Moura
Logtalk developer

Email: <mailto:[email protected]>
Web:   <http://logtalk.org/>
-----------------------------------------------------------------




_______________________________________________
SWI-Prolog mailing list
[email protected]
https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
-------------- next part --------------
HTML attachment scrubbed and removed