3.1.1 File Names and Locations

3.1.1.1 File Name Extensions

The first consideration is what extension to use for the source-files. Tradition calls for .pl, but conflicts with Perl force the use of another extension on systems where extensions have global meaning, such as MS-Windows. On such systems .pro is the common alternative.^{12On MS-Windows, the alternative extension is stored in the registry-key HKEY_CURRENT_USER/Software/SWI/Prolog/fileExtension or HKEY_LOCAL_MACHINE/Software/SWI/Prolog/fileExtension}

All versions of SWI-Prolog load files with the extension .pl as well as with the registered alternative extension without explicitly specifying the extension. For portability reasons we propose the following convention:

If there is no conflict

because you do not use a conflicting application or the system does not force a unique relation between extension and application, use .pl.

With a conflict

choose .pro and use this extension for the files you want to load through your file-manager. Use .pl for all other files for maximal portability.

3.1.1.2 Project Directories

Large projects are generally composed of sub-projects, each using their own directory or directory-structure. If nobody else will ever touch your files and you use only one computer there is little to worry about, but this is rarely the case with a large project.

To improve portability, SWI-Prolog uses the POSIX notation for filenames, which uses the forward slash (/) to separate directories. Just before hitting the file-system it uses prolog_to_os_filename/2 to convert the filename to the conventions used by the hosting operating system. It is strongly advised to write paths using the /, especially on systems using the \ for this purpose (MS-Windows). Using \ violates the portability rules and requires you to double the \ due to the Prolog quoted-atom escape rules.

Portable code should use prolog_to_os_filename/2 to convert computed paths into system-paths when constructing commands for shell/1 and friends.

3.1.1.3 Sub-projects using search-paths

Thanks to Quintus, Prolog adapted an extensible mechanism for searching files using file_search_path/2. This mechanism allows for comfortable and readable specifications.

Suppose you have extensive library packages on graph-algorithms, set-operations and GUI-primitives. These sub-projects are likely candidates for re-use in future projects. A good choice is to create a directory with sub-directories for each of these sub-projects.

Next, there are three options. One is to add the sub-projects to the directory-hierarchy of the current project. Another is to use a completely dislocated directory and finally the sub-project can be added to the SWI-Prolog hierarchy. Using local installation, a typical file_search_path/2 is:

:- prolog_load_context(directory, Dir),
   asserta(user:file_search_path(myapp, Dir)).

user:file_search_path(graph, myapp(graph)).
user:file_search_path(ui,    myapp(ui)).

For using sub-projects in the SWI-Prolog hierarchy one should use the path-alias swi as basis. For a system-wide installation use an absolute-path.

Extensive sub-projects with a small well-defined API should define a load-file using use_module/1 calls to import the various library-components and export the API.