Re: using module as fact store

Thanks. I reviewed through the module mechanism in the manual. Finally I come up with this:
 1 ?- assert(w:e(1,div)).
true.
 2 ?- assert(w:e(2,textbox)).
true.
 3 ?- delete_import_module(w,user).
true.
 4 ?- findall(H,(current_predicate(w:N/A),length(Args,A),H=..[N|Args],clause(w:H,B)),Facts).
Facts = [e(1, div), e(2, textbox)].
  It is cool. Thanks Carlo & Paulo.
 

 ------------------ Original ------------------
  From:  "cc.carlo.cap";<[email protected]>;
 Date:  Wed, Jan 15, 2014 04:53 PM
 To:  "Lumj"<[email protected]>; 
 Cc:  "Paulo Moura"<[email protected]>; "SWI-Prolog"<[email protected]>; 
 Subject:  Re: [SWIPL] using module as fact store

 

  I think you should continue studying available meta programming facilities: for instance, look for
predicate_property, specifically, see imported_from property


HTH Carlo
 


 

 2014/1/15 Lumj <[email protected]>
 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
_______________________________________________
SWI-Prolog mailing list
[email protected]
https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
-------------- next part --------------
HTML attachment scrubbed and removed