Re: predutils package available (Re: PAC library for develop version available)
Kuniaki Mukai <[email protected]> Wed, 1 Oct 2014 21:29:20 +0900
| Newsgroups | gmane.comp.ai.prolog.swi |
|---|---|
| Message-ID | <[email protected]> |
Hi Jan, On Oct 1, 2014, at 16:29, Jan Wielemaker <[email protected]> wrote: > Hi Kuniaki, > > I've deleted the predutils registration. Thank you for spending the extra care. > > ?- pack_install(pac) works fine here. > > I didn't really look into the details why the pack is not processed, > but quite likely it has to do with modulariry and operator usage. That sounds likely. In fact, I am on the way to make the package modular. I know how to do, except the pac top level (user) behaviour around "expand_query". It will take some time. > The pac package adds a lot of really generically named files to your library, > a number of which are not modules and seem to fulfil diverse roles. > Things that server example purposes should go into a directory > `examples` instead of into the prolog directory. Files there are > not analysed and do not end up in your (extended) Prolog library, > so you can put there whatever you like. I see. > Helper files should also be banned from the prolog directory, especially > if they have generic names. Many classical programs have a file `util.pl`. > If we allow for that habbit it packs, library(util) will be ambiguous. > The normal solution is to create a subdirectory, so you get > > pac > pac/prolog/pac.pl > pac/prolog/pac/reduce.pl I see. > Any .pl file below pac/prolog should be a module file and should use > :- use_module(...) to get its requirements. The helper modules in > prolog/pac should typically start with e.g., :- module(pac_reduce, ...) > to avoid name conflicts. Modules should export whatever needs to be > accessible from the outside, including operators. Code using modules > should import the module using use_module/1 or use_module/2 and use > non-qualified calls. I see well. > A good thing to read is Michael Richter's tutorial on modules. > > Writing libraries is a different thing than writing a program in user > space ... I hope this helps Thanks for the quick and long reply. I think it is not difficult to transform the "pac" package into fully modular one in a week, using emacs grep heavily. The library should restrict interference to others as minimal as possible. Of course, I agree on this. Kuniaki > --- Jan > > On 10/01/2014 08:49 AM, Kuniaki Mukai wrote: >>>> This is needed because library(predutils) doesn't export the predicates >>>> from module pac. The documentation on modules should help: >>>> http://swi-prolog.org/pldoc/man?section=modules >> Thanks. I will reread it. Once I had some difficulty to understand >> basic notions on module something like difference between "namespace" >> or "predicatebase". So I skipped it as my usual way. >> I feel I have been paying to the skipping. >> For instance, it is only recent (few hours ago !) for me to notice that >> assert(a:(b:-c)) is not equivalent to assert(a:b :- c). > _______________________________________________ > SWI-Prolog mailing list > [email protected] > https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: <https://lists.iai.uni-bonn.de/pipermail/swi-prolog/attachments/20141001/76ef1955/signature.asc>