@ciao-lang/ts-ciao-interface
Version:
Simple Ciao interface for node.
4 lines • 11.4 kB
HTML
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"/><meta name="viewport" content="width=device-width, initial-scale=1"/><meta name="theme-color" content="#273f79"/><link rel="stylesheet" href="lpdoc.css" type="text/css"/><script type="text/javascript" src="lpdoc.js"></script><title>The Preprocessing Unit — The CiaoPP Program Processor v1.5</title></head><body><div class="lpdoc-page fixleftbar"><a href="#" id="sidebar-toggle-button" class="lpdoc-navbutton"><span id="sidebar-button-arrow">☰</span></a><div id="sidebar" class="lpdoc-sidebar"><div style="height: 40px; margin-left: auto; margin-right: auto"><img src="ciao-logo_autofig.png" width=auto height=100%></div><div class="lpdoc-nav"><span class="lpdoc-on-right"><a class="lpdoc-navbutton" href="Punit.html">↑</a><a class="lpdoc-navbutton" href="Punit.html">←</a><a class="lpdoc-navbutton" href="p_unit.html">→</a><a class="lpdoc-navbutton" href="ciaopp_ref_mansearch.html">🔍</a></span><span><a href="ciaopp_ref_manfulltoc.html">TOC</a></span></div><hr></hr><ul class="lpdoc-itemize-sectpath"><li><a href="ciaopp_ref_man.html">The CiaoPP Program Processor</a> »<br/> </li><li><a href="part_internals.html">PART IV - CiaoPP Internals</a> »<br/> </li><li><a href="Punit.html">The Preprocessing Unit Component</a> »<br/> </li><li><a href=""><strong>The Preprocessing Unit</strong></a></li></ul><hr></hr><em>ON THIS PAGE</em><ul><li><a href="#The preprocessing unit">The preprocessing unit</a></li><li><a href="#Builtin predicates">Builtin predicates</a></li><li><a href="#Native properties">Native properties</a></li><li><a href="#Organization of the code">Organization of the code</a></li></ul></div><div class="lpdoc-main"><div id=""><h1>The Preprocessing Unit</h1><a class="lpdoc-idx-anchor" href="ciaopp_ref_mansearch.html#Punit0"></a>
This component handles data structures for the code of the current module and for all information about it that may be necessary to precompile that module. Since CiaoPP works in a per-module fashion, when preprocessing one module the modules imported by it may not be accessible. However, information on imported predicates may be essential for some manipulations of the current module: e.g., for analyzing it with greater precision. For this reason, information about exported predicates of a module is stored in separate cache files. The cache files of modules imported by the current module are then loaded together with the file of the current module. All the information stored together with the current module is called the preprocessing unit of the current module.<p>Cache files are used to save assertions that refer to exported predicates, properties exported or properties that are used in assertions for exported predicates, and properties used in the definiton of other relevant properties. (The exact definition of what is cached and how the preprocessing unit is obtained from this caches is given in the chapter for <a class="lpdoc-idx-anchor" id="0" href="ciaopp_ref_mansearch.html#p_asr"><tt>p_asr</tt></a>). This facilitates the use within CiaoPP of all information that may be relevant about exported predicates that may be imported into other modules. This information from (user) assertions is extracted from the module code.<p>Other information that may be relevant is that inferred by CiaoPP on its own. The information from analysis that refers to exported predicates of a module is also cached in separate files, so that the preprocessing of other modules that import such predicates can use the information. Currently, separate files are used for user supplied assertions (the so called .asr file) and for information from analysis (the so called .abs file). Module <a class="lpdoc-idx-anchor" id="1" href="ciaopp_ref_mansearch.html#p_asr"><tt>p_asr</tt></a> is in charge of the .asr file and module <a class="lpdoc-idx-anchor" id="2" href="ciaopp_ref_mansearch.html#p_abs"><tt>p_abs</tt></a> is in charge of the .abs files.<p>More information concerning the current module that this component serves includes: initialization directives, entry assertions that may need analysis, whether a predicate is a meta-predicate or a dynamic predicate, whether it is a "builtin", a property, or a native property, etc. In the sections below we explain what is understood by builtin predicate and native property. The complete functionality offered by this component is explained in the following chapters.<p><div id="The preprocessing unit"><h2>The preprocessing unit</h2> <p>In the following, related files refer to files defining modules from which the current module imports a predicate, whether via direct importation or via re-exportation by an imported module. The <em>preprocessing unit</em> <a class="lpdoc-idx-anchor" id="3" href="ciaopp_ref_mansearch.html#preprocessing unit"></a> consists of:<p><ol> <li >the code (and directives) of the current module, <li >the assertions of the current module, <li >the (imported) properties of related files which are used in the previous assertions, <li >the assertions of related files for predicates imported by the current module, <li >the properties of related files (or imported by them) which are used in the previous assertions, <li >the properties transitively used in the definitions of all the previous properties, whichever file they are defined. </ol> <p>Note that once the preprocessing unit of the current module is loaded, every assertion for a predicate of the current module or imported into the current module can be correctly and completely interpreted, since all the properties that may appear in such assertions (or transitively used in the definitions of such properties) are available. This is the main reason for including the preprocessing unit of the current module instead of simply loading the current module itself alone (and some assertions for imported predicates, probably).<p></div><div id="Builtin predicates"><h2>Builtin predicates</h2> <p>A predicate is builtin <a class="lpdoc-idx-anchor" id="4" href="ciaopp_ref_mansearch.html#builtin predicate"></a> if there is information about it built into one of the components of CiaoPP. This is the case, for example, for analyzers. Usually, these predicates are ISO predicates, whose semantics conform with the standard, and thererefore, can be implemented into CiaoPP once and for all. The names used to refer to these predicates are thus usually also the ISO names.<p>However, in a modular system like Ciao, such builtin predicates may be defined in a module, and can be used (imported) or not by the current module. Whether the predicate is visible or not to the current module is solved by looking at the module interface of the current module. The exact name of the predicate (at the source language level) can be known; for example, ISO <tt>var/1</tt> in CiaoPP is <tt>term_typing:var/1</tt>. This name could also be built into CiaoPP, but this would tight CiaoPP to the particular module structure of the library of a system (Ciao, in this case). Instead, there is a dynamic scheme that makes CiaoPP more flexible: To indicate that a given predicate in a given module corresponds to a builtin predicate, the following kind of assertions are used:<p><pre class="lpdoc-codeblock">:- pred var(X) + native(var(X)).
</pre> <p>This assertion in module <tt>term_typing</tt> tells CiaoPP that predicate <tt>term_typing:var(X)</tt> corresponds to the predicate builtin into CiaoPP as <tt>var(X)</tt>. Note that the name <tt>var/1</tt> should be used all throughtout CiaoPP to identify that very same predicate (the one in ISO by that name, in this case). This is mandatory.<p>Note also that with the above scheme, the only real predicate name that is built into CiaoPP is that for the property <tt>native(Pred,Name)</tt>, which currently is precisely <tt>native(Pred,Name)</tt> (which is currently defined in library module <a class="lpdoc-idx-anchor" id="5" href="ciaopp_ref_mansearch.html#engine(basic_props)"><tt>engine(basic_props)</tt></a>).<p></div><div id="Native properties"><h2>Native properties</h2> <p>A property in Ciao is a predicate. Certain properties are used within CiaoPP in a native way, which means that some component understands the property natively (for example, an analysis for groundness understands the property of being ground). These properties are called <em>native properties</em> <a class="lpdoc-idx-anchor" id="6" href="ciaopp_ref_mansearch.html#native properties"></a>.<p>The same problem above for builtin predicates occurs also for native properties, and the same solution has been given to the problem also in this case. To indicate that a given predicate corresponds to a property understood natively by CiaoPP the following kind of assertions are used:<p><pre class="lpdoc-codeblock">:- prop var(X) + native(free(X)).
</pre> <p>This is interpreted by CiaoPP so that predicate <tt>term_typing:var(X)</tt> corresponds to the native property identified in CiaoPP as <tt>free(X)</tt>. Note that the name <tt>free/1</tt> should be used all throughtout CiaoPP to identify that property. The names of native properties are defined in <tt>native:native/1</tt>.<p>The (default) predicates that are used as source language level counterparts of the native property names are gathered together in a Ciao library module that currently is <a class="lpdoc-idx-anchor" id="7" href="ciaopp_ref_mansearch.html#library(assertions/native_props)"><tt>library(assertions/native_props)</tt></a>.<p>There is an scheme for translating predicate property names to native property names upon input of the current module, and native property names back to predicate property names upon output that is described in the chapter about module <a class="lpdoc-idx-anchor" id="8" href="domains.html"><tt>domains</tt></a>.<p></div><div id="Organization of the code"><h2>Organization of the code</h2> <p>The organization of the code of this component is as follows:<p><img src="punit_autofig.png"> <p>Module <a class="lpdoc-idx-anchor" id="9" href="p_unit.html"><tt>p_unit</tt></a> is in charge of supporting all other CiaoPP components when they require information about the program. Module <a class="lpdoc-idx-anchor" id="10" href="ciaopp_ref_mansearch.html#p_asr"><tt>p_asr</tt></a> is in charge of processing the .asr files and gathering together the preprocessing unit for the current module. Module <a class="lpdoc-idx-anchor" id="11" href="ciaopp_ref_mansearch.html#assrt_norm"><tt>assrt_norm</tt></a> is used to normalize assertions. Module <a class="lpdoc-idx-anchor" id="12" href="ciaopp_ref_mansearch.html#p_abs"><tt>p_abs</tt></a> is in charge of reading .abs files and writing them. Module <a class="lpdoc-idx-anchor" id="13" href="ciaopp_ref_mansearch.html#assrt_db"><tt>assrt_db</tt></a> maintains the database of assertions, module <a class="lpdoc-idx-anchor" id="14" href="ciaopp_ref_mansearch.html#clause_db"><tt>clause_db</tt></a> the database of clauses, and module <a class="lpdoc-idx-anchor" id="15" href="ciaopp_ref_mansearch.html#itf_db"><tt>itf_db</tt></a> the database of information related to the module interface of the current module.<p>Each of the modules is documented in the following chapters.<p></div><br/></div><div class="lpdoc-footer">Generated with LPdoc using Ciao</div></div><div class="lpdoc-clearer"></div></div></body></html>