Re: using module as fact store

I tried this:
 1 ?- current_predicate(w:P).
false.
 2 ?- w:current_predicate(N,H).
false.
  
  //so far it is good
  
 3 ?- w:current_predicate(N,H),clause(H,B).
N = current_predicate,
H = current_predicate(_G1868, _G1877:_G1878),
B = ((var(_G1877);var(_G1878)), !, generate_current_predicate(_G1868, _G1877, _G1878)) ;
N = current_predicate,
H = current_predicate(_G1868, _G1869),
B = ('$c_current_predicate'(_G1868, _G1869), '$defined_predicate'(_G1869), !) ;
...
 ...
  
 //And after this, we get:
4 ?- current_predicate(w:P).
P = current_predicate/2 ;
false.

 The current_predicate predicate is again enumerated out.
 

 ------------------ Original ------------------
  From:  "Lumj";<[email protected]>;
 Date:  Wed, Jan 15, 2014 01:43 AM
 To:  "Paulo Moura"<[email protected]>; 
 Cc:  "SWI-Prolog"<[email protected]>; 
 Subject:  Re: [SWIPL] 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
_______________________________________________
SWI-Prolog mailing list
[email protected]
https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
-------------- next part --------------
HTML attachment scrubbed and removed