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>