Logtalk 2.25.0 files.
git-svn-id: https://yap.svn.sf.net/svnroot/yap/trunk@1288 b08c6af1-5177-4d33-ba66-4b1c6b8b522a
This commit is contained in:
@@ -32,37 +32,10 @@ One of the advantages of a system like Logtalk is that it enable us to use the c
|
||||
<h3>Source files<a name="source_files"></a></h3>
|
||||
|
||||
<p>
|
||||
A Logtalk source file must contain only one entity, either an object, a category, or a protocol. It is recommended that each source file be named after the entity identifier. For parametric objects, the identifier arity can be appended to the identifier functor. By default, all Logtalk source files use the extension <code>.lgt</code> but this is optional and can be set in the configuration files. Compiled source files (by the Logtalk preprocessor) have, by default, a <code>.pl</code> extension. Again, this can be set to match the needs of a particular Prolog compiler in the corresponding configuration file. For example, we may define an object named <code>vehicle</code> and save it in a <code>vehicle.lgt</code> source file that will be compiled to a <code>vehicle.pl</code> Prolog file. If we have a <code>sort(_)</code> parametric object we can save it on a <code>sort1.lgt</code> source file that will be compiled to a <code>sort1.pl</code> Prolog file. This name scheme helps avoid file name conflicts (remember that all Logtalk entities share the same name space).
|
||||
Logtalk source files may contain any number of objects, categories, or protocols. If you prefer to define each entity in its own source file, then it is recommended that the source file be named after the entity identifier. For parametric objects, the identifier arity can be appended to the identifier functor. By default, all Logtalk source files use the extension <code>.lgt</code> but this is optional and can be set in the configuration files. Compiled source files (by the Logtalk preprocessor) have, by default, a <code>.pl</code> extension. Again, this can be set to match the needs of a particular Prolog compiler in the corresponding configuration file. For example, we may define an object named <code>vehicle</code> and save it in a <code>vehicle.lgt</code> source file that will be compiled to a <code>vehicle.pl</code> Prolog file. If we have a <code>sort(_)</code> parametric object we can save it on a <code>sort1.lgt</code> source file that will be compiled to a <code>sort1.pl</code> Prolog file. This name scheme helps avoid file name conflicts (remember that all Logtalk entities share the same name space).
|
||||
</p>
|
||||
<p>
|
||||
Any Logtalk source file can contain arbitrary directives and clauses before the opening entity directive. These directives and clauses will not be compiled by the Logtalk preprocessor and will be copied unchanged to the beginning of the corresponding Prolog output file. This feature is included to help the integration of Logtalk with other Prolog extensions such as, for example, constraint programming extensions.
|
||||
</p>
|
||||
|
||||
<h3>Source metafiles<a name="source_metafiles"></a></h3>
|
||||
|
||||
<p>
|
||||
Sometimes is useful to be able to define several entities in the same source file. This can be accomplished by using Logtalk <em>source metafiles</em>. Logtalk source metafiles are identified by the extension <code>.mlgt</code>. A metafile can be interpreted as the concatenation of source files. Logtalk compiles a source metafile by automatically splitting it into individual entity source files. In addition, two helper files for compiling and loading the extracted entity files are generated. The names of these helper files are the concatenation of the metafile name with the sufixes <code>_load</code> and <code>_compile</code>. Both helper files use the extension <code>.lgt</code>. For example, splitting a metafile named <code>my_program.mlgt</code> results in helper files named <code>my_program_compile.mlgt</code> and <code>my_program_load.lgt</code>.
|
||||
</p>
|
||||
<p>
|
||||
Source metafiles may be compiled and loaded in the same way as single-entity source files by using the Logtalk built-in predicates <code>logtalk_compile/1-2</code> and <code>logtalk_load/1-2</code> (omitting the <code>.mlgt</code> file name extension). For example, assuming a metafile named <code>my_program.mlgt</code>, the following call:
|
||||
</p>
|
||||
<pre>
|
||||
:- logtalk_compile(my_program).
|
||||
</pre>
|
||||
<p>
|
||||
results in the compilation of all extracted entity files. Likewise, the call:
|
||||
</p>
|
||||
<pre>
|
||||
:- logtalk_load(my_program).
|
||||
</pre>
|
||||
<p>
|
||||
results in the compilation and loading of all extracted entity files. If compilation options are given (through the use of the predicates <code>logtalk_compile/2</code> or <code>logtalk_load/2</code>), these will be used in the compilation and loading of each extracted entity file.
|
||||
</p>
|
||||
<p>
|
||||
Currently, only limited error checking is performed during extraction of individual source files from a source metafile. The extraction process is guided by the occurrence of opening and closing entity directives, with all terms being copied to the generated files without further analysis.
|
||||
</p>
|
||||
<p>
|
||||
As with source files, clauses and directives occurring before an entity opening directive are copied unchanged to the extracted entity source file. In the unlikely event that a source metafile does not contain any entity definitions, any predicate clauses and directives it might contain are copied, unchanged, to the generated loading helper file (but not to the generated compiling helper file).
|
||||
Logtalk source files may contain arbitrary Prolog directives and clauses interleaved with Logtalk entity definitions. These directives and clauses will not be compiled by the Logtalk preprocessor and will be copied unchanged to the corresponding Prolog output file. This feature is included to help the integration of Logtalk with other Prolog extensions such as, for example, constraint programming extensions.
|
||||
</p>
|
||||
|
||||
<h3>Loader utility files<a name="loaders"></a></h3>
|
||||
@@ -108,7 +81,7 @@ This allows us to load a library source file without the need to first change th
|
||||
The best way to take advantage of this feature is to load at startup a source file containing an <code>initialization/1</code> directive which asserts all the <code>logtalk_library_path/2</code> clauses needed for all available libraries. This allows us to load library source files or entire libraries without worrying about libraries paths, improving code portability.
|
||||
</p>
|
||||
<p>
|
||||
Unfortunately, a few Prolog compilers do not support the <code><library>(<entity>)</code> notation. In this case, you will need to set the working directory to be the one that contains the entity file in order to load it.
|
||||
Unfortunately, a few Prolog compilers do not support the <code><library>(<source file>)</code> notation. In this case, you will need to set the working directory to be the one that contains the source file in order to load it.
|
||||
</p>
|
||||
|
||||
<h3>Portable programs<a name="portability"></a></h3>
|
||||
@@ -177,7 +150,7 @@ Copyright © <a href="mailto:pmoura@logtalk.org">Paulo Moura</a> — <a
|
||||
</div>
|
||||
|
||||
<div class="footer">
|
||||
<p><span class="bleft"><a href="http://validator.w3.org/check/referer">XHTML</a> + <a href="http://jigsaw.w3.org/css-validator/check/referer">CSS</a></span><span class="bright">Last updated on: February 6, 2005</span></p>
|
||||
<p><span class="bleft"><a href="http://validator.w3.org/check/referer">XHTML</a> + <a href="http://jigsaw.w3.org/css-validator/check/referer">CSS</a></span><span class="bright">Last updated on: April 27, 2005</span></p>
|
||||
</div>
|
||||
</body>
|
||||
</html>
|
||||
|
Reference in New Issue
Block a user