Re: predutils package available (Re: PAC library for develop version available)

Hi Jan,

I have updated pac to V-0.5.6 from V-0.5.5, following the guideline 
in the tutorial in your previous message:
1) no predicates defined in pac can be called without module prefix qualififcation,
2) operator declarations are local to pac, 
3) renaming module names attaching prefix "pac_" to avoid possible 
confusions with that of other packages.

>> Writing libraries is a different thing than writing a program in user
>> space ...  I hope this helps

Deep words. I feel I have seen something of library builder's invisible efforts
for others happy life. 

By the way, I would like to ask you an urgent and maybe stupid
question about module.  I thought exported names can be used from any
oother contexts, i.e., globally, like builtin append/3.  But a simple
experiment shows that it is not the case. So my question is: in
what contexts an exported name can be used without putting module
prefix before the name ? I have read the recommended document, but I am
afraid I have missed the point again.

Kuniaki


On Oct 1, 2014, at 16:29, Jan Wielemaker <[email protected]> wrote:

> Hi Kuniaki,
> 
> I've deleted the predutils registration.
> 
> ?- 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.  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.
> 
> 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
> 
> 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.
> 
> 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
> 
> 		--- 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/20141002/db5e2ec5/signature.asc>