AppliedLogicSystems
Should all_procedures/4 also search the library? Or should we have companion procedure?
The form for all_procedures/4 is: all_procedures(Module, Pred, Arity, Ref), where Ref is the database reference for the entry for Pred/Arity in Module. Although Module, Pred, Arity are available in *.alb, there is no Ref until that library file is loaded. There are already companions:
procedures/4 — retrieves all Prolog-defined procedures all_procedures/4 — retrieves all Prolog- or C-defined procedures all_ntbl_entries/4 — retrieves all name table entries
The library mechanism works by having an entry in the name table for all library predicates, that causes the appropriate lib file to be loaded if a lib predicate is called. So there are name table entries for all predicates library files with an alb companion, for example ( list_diff/3 is in library/listutl1.pro ):
?- all_ntbl_entries(M, list_diff, 3, R). M=builtins R=0
The difficulty here is that C-defined builtins also get R=0. However, at the system level, we can certainly recognize that a name table entry is for a library predicate vs a C-defined predicate. So we could exploit that to define library_procedures/3, library_procedures(Module, Pred, Arity), or we could use a different return value for R in all_procedures/4 and all_ntbl_entries/4 to distinguish between library predicates and C-defined procedures (maybe -1 for library predicates ??).
procedures/all_procedures are used extensively, so it is probably best not to redefine them. Within the builtins module, procedures/5 or '$procinfo' can be used to extract more info. Is there a need for user module access to unloaded library procedures?
On Dec 8, 2018, at 10:23 AM, Chuck Houpt [email protected] wrote:
procedures/all_procedures are used extensively, so it is probably best not to redefine them. Valid point. Within the builtins module, procedures/5 or '$procinfo' can be used to extract more info. Is there a need for user module access to unloaded library procedures? Extend cref to cover library preds.
So best to define something new which won’t cause any conflicts with procedures/all_procedures, but give the coverage necessary.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.