fix links
This commit is contained in:
parent
1206035805
commit
7c4014d15b
@ -1,20 +1,21 @@
|
|||||||
Downloading and Installing YAP {#INSTALL}
|
lDownloading and Installing YAP {#INSTALL}
|
||||||
===========================
|
===========================
|
||||||
|
|
||||||
This text includes instructions to download and install YAP.
|
This text includes instructions to download and install YAP.
|
||||||
|
|
||||||
[TOC]
|
[TOC]
|
||||||
|
|
||||||
## Downloading YAP {#Download}
|
Downloading YAP {#Download}
|
||||||
|
----------------
|
||||||
|
|
||||||
The latest development version of Yap-6 is available source-only
|
The latest development version of Yap-6 is available source-only
|
||||||
through GIT repositories. The main reference repository is at
|
through GIT repositories. The main reference repository is at
|
||||||
|
|
||||||
+ [github](https://github.com/vscosta/yap-6.3)
|
+ development branch: [github](https://github.com/vscosta/yap-6.3)
|
||||||
|
|
||||||
We store an older version of YAP at:
|
We store an older version of YAP at:
|
||||||
|
|
||||||
+ [sourceforge](http://sourceforge.net/p/yap/yap-6.3)
|
+ snapshots: [sourceforge](http://sourceforge.net/p/yap/yap-6.3)
|
||||||
|
|
||||||
Please just use `git clone` to obtain the distribution. Ie, to download YAP from the command line please type:
|
Please just use `git clone` to obtain the distribution. Ie, to download YAP from the command line please type:
|
||||||
|
|
||||||
@ -26,22 +27,23 @@ The first argument is the repository, the last argument is the (optional) target
|
|||||||
|
|
||||||
There are a variety of graphical interfaces to `git`, including GitHub's own [GitHub Desktop](https://desktop.github.com/) that supports Microsoft Windows and Apple OSX. A list with GUI applications, editor integration, and much more can be found at the [git Wiki](https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools),
|
There are a variety of graphical interfaces to `git`, including GitHub's own [GitHub Desktop](https://desktop.github.com/) that supports Microsoft Windows and Apple OSX. A list with GUI applications, editor integration, and much more can be found at the [git Wiki](https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools),
|
||||||
|
|
||||||
## Download Options
|
### Download Options
|
||||||
|
|
||||||
It may be useful to know:
|
It may be useful to know:
|
||||||
|
|
||||||
+ If you are have limited bandwith or disk spaceq, consider using
|
+ If you are have limited bandwith or disk spaceq, consider using
|
||||||
`git clone --depth XX` to only include the last `XX` commits.
|
`git clone --depth XX` to only include the last `XX` commits.
|
||||||
|
|
||||||
+ Older versions of YAP were distributed with modules. YAP-6.3.5 is
|
+ Older versions of YAP were distributed with modules. YAP-6.3.5 is
|
||||||
a single package, and it does not need `git submodule`.
|
a single package, and it does not need `git submodule`.
|
||||||
|
|
||||||
+ The GitHub site includes a number of companion packages for YAP,
|
+ The GitHub site includes a number of companion packages for YAP,
|
||||||
including [doxygen-yap](https://github.com/vscosta/doxygen-yap), a
|
including [doxygen-yap](https://github.com/vscosta/doxygen-yap), a
|
||||||
version of doxygen adapted to Prolog that was used to generate
|
version of doxygen adapted to Prolog that was used to generate
|
||||||
these documents.
|
these documents.
|
||||||
|
|
||||||
## Compiling YAP {#CompilingYAP}
|
Compiling YAP {#CompilingYAP}
|
||||||
|
----------------
|
||||||
|
|
||||||
YAP-6.3.4 is a [cmake](www.cmake.org) based
|
YAP-6.3.4 is a [cmake](www.cmake.org) based
|
||||||
system. We use `cmake` because it supports mosts popular software, can
|
system. We use `cmake` because it supports mosts popular software, can
|
||||||
@ -49,12 +51,12 @@ generate Makefiles, Ninja, Apple's XCode, VisualStudio and ANdroid
|
|||||||
Studio, and because it includes packaging suppport, The steps required
|
Studio, and because it includes packaging suppport, The steps required
|
||||||
to install core YAP under `cmake`:
|
to install core YAP under `cmake`:
|
||||||
|
|
||||||
#### The compiler
|
### The compiler
|
||||||
|
|
||||||
*Status as of early 2017*
|
*Status as of early 2017*
|
||||||
|
|
||||||
YAP should compile well under the [GNU-CC](https://gcc.gnu.org/)
|
YAP should compile well under the [GNU-CC](https://gcc.gnu.org/)
|
||||||
and the [C-LANG]https://clang.llvm.org/() families, that are
|
and the [C-LANG](https://clang.llvm.org/) families, that are
|
||||||
available across most configurations. It sshould also compile well
|
available across most configurations. It sshould also compile well
|
||||||
undder Intel `icc`.
|
undder Intel `icc`.
|
||||||
|
|
||||||
@ -66,7 +68,7 @@ to install core YAP under `cmake`:
|
|||||||
YAP compiles cleanly under cross-compilers, and we have used the
|
YAP compiles cleanly under cross-compilers, and we have used the
|
||||||
crosss-compilation system [mxe](http://mxe.cc/) system with good results.
|
crosss-compilation system [mxe](http://mxe.cc/) system with good results.
|
||||||
|
|
||||||
## cmake
|
### cmake
|
||||||
|
|
||||||
All Linux and BSD distributions include `cmake`, so
|
All Linux and BSD distributions include `cmake`, so
|
||||||
does [Homebrew](https://brew.sh/)
|
does [Homebrew](https://brew.sh/)
|
||||||
@ -76,33 +78,33 @@ and [cygwin](http://www.cygwin.org/) for WIN32. Android Studio has
|
|||||||
native support for `cmake`since 2.1, although we advise to use
|
native support for `cmake`since 2.1, although we advise to use
|
||||||
2.2. Last, there are excellent plugins for the Visual Codes. In case
|
2.2. Last, there are excellent plugins for the Visual Codes. In case
|
||||||
you need a recent version, consider using pre-compiled binaries at
|
you need a recent version, consider using pre-compiled binaries at
|
||||||
the [CMake site](https://www.cmake.org).
|
the [CMake site](https://www.cmake.org).
|
||||||
|
|
||||||
If you have an older Linux you may need to compile from source,
|
If you have an older Linux you may need to compile from source,
|
||||||
available at GitHub.
|
available at GitHub.
|
||||||
|
|
||||||
## Ensure that you have other necessary packages installed:
|
### Ensure that you have other necessary packages installed:
|
||||||
|
|
||||||
+ YAP requires [gmp]{https://gmplib.org/} for infinite precision
|
+ YAP requires [gmp]{https://gmplib.org/} for infinite precision
|
||||||
integer and rational. Please ensure the development pacakage
|
integer and rational. Please ensure the development pacakage
|
||||||
is installed in Linux: `(lib)gmp-dev(el). In the Mac and
|
is installed in Linux: `(lib)gmp-dev(el). In the Mac and
|
||||||
WIN32, you can obtain GMPlib from the pakage collections mentioned above.
|
WIN32, you can obtain GMPlib from the pakage collections mentioned above.
|
||||||
|
|
||||||
The [MPIR]{http://mpir.org} library is compatible with GMPlib,
|
The [MPIR]{http://mpir.org} library is compatible with GMPlib,
|
||||||
and has good support for VC++.
|
and has good support for VC++.
|
||||||
|
|
||||||
+ The [readline]() library provides line-editing and command
|
+ The [readline]() library provides line-editing and command
|
||||||
history. In Linux, make sure you have the development package.
|
history. In Linux, make sure you have the development package.
|
||||||
|
|
||||||
Readline is disabled by default in WIN32. OSX is distributed with a line editing library that includes a subset of readline. We advise against using that library.
|
Readline is disabled by default in WIN32. OSX is distributed with a line editing library that includes a subset of readline. We advise against using that library.
|
||||||
|
|
||||||
- To use YAP as a library in [Python]() you need the [SWIG]()
|
- To use YAP as a library in [Python]() you need the [SWIG]()
|
||||||
interface generator and python3-dev. SWIG and Python binaries can be
|
interface generator and python3-dev. SWIG and Python binaries can be
|
||||||
easily obtained for all these platfors
|
easily obtained for all these platfors
|
||||||
|
|
||||||
+ make sure to install Python-3, and not Python-2,
|
+ make sure to install Python-3, and not Python-2,
|
||||||
|
|
||||||
## Compile and Install
|
### Compile and Install
|
||||||
|
|
||||||
1: Create a directory, say `Build` and `cd` to the directory (`cd Build`).
|
1: Create a directory, say `Build` and `cd` to the directory (`cd Build`).
|
||||||
*YAP should not be compiled at its rootxo directory, some packages do not allow for that.
|
*YAP should not be compiled at its rootxo directory, some packages do not allow for that.
|
||||||
@ -116,7 +118,7 @@ available at GitHub.
|
|||||||
5: If you feel satisfied with the result, do `make install`.
|
5: If you feel satisfied with the result, do `make install`.
|
||||||
* In most systems you will need to be superuser in order to do `make install` and `make info` on the standard directories.
|
* In most systems you will need to be superuser in order to do `make install` and `make info` on the standard directories.
|
||||||
|
|
||||||
### Tuning the Functionality of YAP
|
#### Tuning the Functionality of YAP
|
||||||
|
|
||||||
By default, YAP supports tabling, depth first search, and most features found in
|
By default, YAP supports tabling, depth first search, and most features found in
|
||||||
modern Prologs. In some cases, you may want to suport extra features, or reduce system size.
|
modern Prologs. In some cases, you may want to suport extra features, or reduce system size.
|
||||||
@ -177,53 +179,53 @@ You can also use `xcodebuild` from the command line.
|
|||||||
|
|
||||||
Bext follow instructions to fully compile YAP:
|
Bext follow instructions to fully compile YAP:
|
||||||
|
|
||||||
## Compilation Notes for OSX/Brew
|
### Compilation Notes for OSX/Brew
|
||||||
|
|
||||||
Next follows a detailed description of a full install of YAP, including all the packages that YAP can use:
|
Next follows a detailed description of a full install of YAP, including all the packages that YAP can use:
|
||||||
|
|
||||||
1. Install the XCode toolkit from the Apple App Store (you may have to register as a developer).
|
1. Install the XCode toolkit from the Apple App Store (you may have to register as a developer).
|
||||||
|
|
||||||
2. Install a package manager, such as [brew](http://brew.sh),
|
2. Install a package manager, such as [brew](http://brew.sh),
|
||||||
|
|
||||||
3. You will need `cmake` and `gmp`: both are available in brew.
|
3. You will need `cmake` and `gmp`: both are available in brew.
|
||||||
|
|
||||||
4. other brew packages you may want to install: `gecode`, `libxml2`, `openssl`,
|
4. other brew packages you may want to install: `gecode`, `libxml2`, `openssl`,
|
||||||
`mariadb`, `openmpi`, `postgresql`, `raptor`,
|
`mariadb`, `openmpi`, `postgresql`, `raptor`,
|
||||||
`sqlite3`, `swig`, `unixodbc`. Note that some of them may be preconditions
|
`sqlite3`, `swig`, `unixodbc`. Note that some of them may be preconditions
|
||||||
to other packages.
|
to other packages.
|
||||||
|
|
||||||
5. to install [cudd](http://vlsi.colorado.edu/~fabio/CUDD), a package used by ProbLog and cplint, just use:
|
5. to install [cudd](http://vlsi.colorado.edu/~fabio/CUDD), a package used by ProbLog and cplint, just use:
|
||||||
~~~~~
|
~~~~~
|
||||||
brew tap mht208/formal
|
brew tap mht208/formal
|
||||||
brew install cudd
|
brew install cudd
|
||||||
~~~~~
|
~~~~~
|
||||||
|
|
||||||
6. To use [R](https://www.r-project.org), you must download the `R` distribution from one of the many `R` mirrors.
|
6. To use [R](https://www.r-project.org), you must download the `R` distribution from one of the many `R` mirrors.
|
||||||
|
|
||||||
6. To use [Java](https://www.java.com), you should download the Oracle distributed JDK.
|
6. To use [Java](https://www.java.com), you should download the Oracle distributed JDK.
|
||||||
|
|
||||||
6. When installing [Python](https://www.python.org), verify which python you
|
6. When installing [Python](https://www.python.org), verify which python you
|
||||||
are using.
|
are using.
|
||||||
|
|
||||||
7. There may be conflict between original OSX and the brew packages (eg, `openssl`, `python`, and `sqlite3`. If you prefer leaning on brew:
|
7. There may be conflict between original OSX and the brew packages (eg, `openssl`, `python`, and `sqlite3`. If you prefer leaning on brew:
|
||||||
~~~~~
|
~~~~~
|
||||||
cmake -DOPENSSL_ROOT_DIR=/usr/local/opt/openssl ..
|
cmake -DOPENSSL_ROOT_DIR=/usr/local/opt/openssl ..
|
||||||
~~~~~
|
~~~~~
|
||||||
|
|
||||||
## Compilation Notes for Android
|
### Compilation Notes for Android
|
||||||
|
|
||||||
Next we present the compilation process for Android. The environment is an OSX, but steps
|
Next we present the compilation process for Android. The environment is an OSX, but steps
|
||||||
should be similar for Linux machines. We assume you have downloaded both the Android NDK and the Android SDK.
|
should be similar for Linux machines. We assume you have downloaded both the Android NDK and the Android SDK.
|
||||||
|
|
||||||
1. Reserve a directory for compilation:
|
1. Reserve a directory for compilation:
|
||||||
~~~~~
|
~~~~~
|
||||||
mkdir android
|
mkdir android
|
||||||
cd android
|
cd android
|
||||||
~~~~~
|
~~~~~
|
||||||
|
|
||||||
2. Get the [GMP-android](https://github.com/Rupan/gmp) port.
|
2. Get the [GMP-android](https://github.com/Rupan/gmp) port.
|
||||||
|
|
||||||
2. Call `cmake`:
|
2. Call `cmake`:
|
||||||
~~~~~
|
~~~~~
|
||||||
export ANDROID_NDK=/Volumes/Transcend/vsc/android-ndk-r11c; \
|
export ANDROID_NDK=/Volumes/Transcend/vsc/android-ndk-r11c; \
|
||||||
export ANDROID_SDK=/Volumes/Transcend/vsc/AndroidSDK;\
|
export ANDROID_SDK=/Volumes/Transcend/vsc/AndroidSDK;\
|
||||||
|
@ -1,9 +1,11 @@
|
|||||||
|
|
||||||
@defgroup AttributedVariables Attributed Variables and Co-Routining
|
|
||||||
|
|
||||||
@ingroup extensions
|
@defgroup AttributedVariables Attributed Variables
|
||||||
|
|
||||||
@{
|
@{
|
||||||
|
|
||||||
|
|
||||||
|
@ingroup extensions
|
||||||
|
|
||||||
YAP supports attributed variables, originally developed at OFAI by
|
YAP supports attributed variables, originally developed at OFAI by
|
||||||
Christian Holzbaur. Attributes are a means of declaring that an
|
Christian Holzbaur. Attributes are a means of declaring that an
|
||||||
@ -28,8 +30,10 @@ work with. Most packages included in YAP that use attributed
|
|||||||
variables, such as CHR, CLP(FD), and CLP(QR), rely on the SWI-Prolog
|
variables, such as CHR, CLP(FD), and CLP(QR), rely on the SWI-Prolog
|
||||||
awi interface.
|
awi interface.
|
||||||
|
|
||||||
@defgroup SICS_attributes SICStus Style attribute declarations.
|
@defgroup SICS_attributes SICStus Style attribute declarations.
|
||||||
|
|
||||||
|
@{
|
||||||
|
@ingroup AttributedVariables
|
||||||
|
|
||||||
The YAP library `atts` implements attribute variables in the style of
|
The YAP library `atts` implements attribute variables in the style of
|
||||||
SICStus Prolog. Attributed variables work as follows:
|
SICStus Prolog. Attributed variables work as follows:
|
||||||
@ -82,10 +86,9 @@ mechanism is used for this purpose.
|
|||||||
|
|
||||||
The attribute manipulation predicates always work as follows:
|
The attribute manipulation predicates always work as follows:
|
||||||
|
|
||||||
+ The first argument is the unbound variable associated with
|
+ The first argument is the unbound variable associated with
|
||||||
attributes,
|
attributes,
|
||||||
|
+ The second argument is a list of attributes. Each attribute will
|
||||||
+ The second argument is a list of attributes. Each attribute will
|
|
||||||
be a Prolog term or a constant, prefixed with the <tt>+</tt> and <tt>-</tt> unary
|
be a Prolog term or a constant, prefixed with the <tt>+</tt> and <tt>-</tt> unary
|
||||||
operators. The prefix <tt>+</tt> may be dropped for convenience.
|
operators. The prefix <tt>+</tt> may be dropped for convenience.
|
||||||
|
|
||||||
@ -100,9 +103,9 @@ attempting to unify an attributed variable which might have attributes
|
|||||||
in some _Module_.
|
in some _Module_.
|
||||||
|
|
||||||
|
|
||||||
At execution conclusion, attributes still unsatisfied are presented as
|
Attributes are usually presented as goals. The following routines are
|
||||||
goals. The following routines are used by built-in predicates such as
|
used by built-in predicates such as call_residue/2 and by the
|
||||||
call_residue/2 and by the Prolog top-level to display attributes:
|
Prolog top-level to display attributes:
|
||||||
|
|
||||||
|
|
||||||
Constraint solvers must be able to project a set of constraints to a set
|
Constraint solvers must be able to project a set of constraints to a set
|
||||||
@ -270,11 +273,15 @@ variables only. More complicated interactions are likely to be found
|
|||||||
in more sophisticated solvers. The corresponding
|
in more sophisticated solvers. The corresponding
|
||||||
verify_attributes/3 predicates would typically refer to the
|
verify_attributes/3 predicates would typically refer to the
|
||||||
attributes from other known solvers/modules via the module prefix in
|
attributes from other known solvers/modules via the module prefix in
|
||||||
Module:get_atts/2.
|
Module:get_atts/2`.
|
||||||
|
|
||||||
|
@}
|
||||||
|
|
||||||
|
|
||||||
hProlog and SWI-Prolog style Attribute Declarations {#New_Style_Attribute_Declarations}
|
@defgroup New_Style_Attribute_Declarations hProlog and SWI-Prolog style Attribute Declarations
|
||||||
------------------------------------------------
|
|
||||||
|
@{
|
||||||
|
@ingroup AttributedVariables
|
||||||
|
|
||||||
The following documentation is taken from the SWI-Prolog manual.
|
The following documentation is taken from the SWI-Prolog manual.
|
||||||
|
|
||||||
@ -288,26 +295,23 @@ hProlog and SWI-Prolog style Attribute Declarations {#New_Style_Att
|
|||||||
|
|
||||||
~~~~~
|
~~~~~
|
||||||
:- module(domain,
|
:- module(domain,
|
||||||
[ domain/2 % Var, ?Domain %
|
[ domain/2 % Var, ?Domain %
|
||||||
]).
|
]).
|
||||||
:- use_module(library(ordsets)).
|
:- use_module(library(ordsets)).
|
||||||
|
|
||||||
domain(X, Dom) :-
|
domain(X, Dom) :-
|
||||||
var(Dom), !,
|
var(Dom), !,
|
||||||
get_attr(X, domain, Dom).
|
get_attr(X, domain, Dom).
|
||||||
domain(X, List) :-
|
domain(X, List) :-
|
||||||
list_to_ord_set(List, Domain),
|
list_to_ord_set(List, Domain),
|
||||||
put_attr(Y, domain, Domain),
|
put_attr(Y, domain, Domain),
|
||||||
X = Y.
|
X = Y.
|
||||||
|
|
||||||
~~~~~
|
~~~~~
|
||||||
|
|
||||||
The next predicate is called *after* _X_, the attributed variable with attribute value _Domain_ has been
|
An attributed variable with attribute value Domain has been assigned the value Y.
|
||||||
assigned the value Y.
|
|
||||||
|
|
||||||
|
|
||||||
~~~~~
|
~~~~~
|
||||||
attr_unify_hook(Domain, Y) :-
|
attr_unify_hook(Domain, Y) :-
|
||||||
( get_attr(Y, domain, Dom2)
|
( get_attr(Y, domain, Dom2)
|
||||||
-> ord_intersection(Domain, Dom2, NewDomain),
|
-> ord_intersection(Domain, Dom2, NewDomain),
|
||||||
( NewDomain == []
|
( NewDomain == []
|
||||||
@ -322,7 +326,7 @@ attr_unify_hook(Domain, Y) :-
|
|||||||
).
|
).
|
||||||
~~~~~
|
~~~~~
|
||||||
|
|
||||||
The user defined attribute_goals/1 attributes from this module to residual goals
|
Translate attributes from this module to residual goals:
|
||||||
|
|
||||||
~~~~~
|
~~~~~
|
||||||
attribute_goals(X) -->
|
attribute_goals(X) -->
|
||||||
@ -330,7 +334,7 @@ attribute_goals(X) -->
|
|||||||
[domain(X, List)].
|
[domain(X, List)].
|
||||||
~~~~~
|
~~~~~
|
||||||
|
|
||||||
Before explaining the code in detail we give some example queries:
|
Before explaining the code we give some example queries:
|
||||||
|
|
||||||
The predicate `domain/2` fetches (first clause) or assigns
|
The predicate `domain/2` fetches (first clause) or assigns
|
||||||
(second clause) the variable a <em>domain</em>, a set of values it can
|
(second clause) the variable a <em>domain</em>, a set of values it can
|
||||||
@ -348,8 +352,12 @@ attribute_goals(X) -->
|
|||||||
remaining attributes to user-readable goals that, when executed, reinstate
|
remaining attributes to user-readable goals that, when executed, reinstate
|
||||||
these attributes.
|
these attributes.
|
||||||
|
|
||||||
Co-routining {#CohYroutining}
|
@}
|
||||||
------------
|
|
||||||
|
@defgroup CohYroutining Co-routining
|
||||||
|
|
||||||
|
@{
|
||||||
|
@ingroup AttributedVariables
|
||||||
|
|
||||||
Prolog uses a simple left-to-right flow of control. It is sometimes
|
Prolog uses a simple left-to-right flow of control. It is sometimes
|
||||||
convenient to change this control so that goals will only execute when
|
convenient to change this control so that goals will only execute when
|
||||||
@ -362,27 +370,31 @@ attributed variables to implement co-routining.
|
|||||||
|
|
||||||
Two declarations are supported:
|
Two declarations are supported:
|
||||||
|
|
||||||
+ block/1
|
+ block/1
|
||||||
The argument to `block/1` is a condition on a goal or a conjunction
|
The argument to `block/1` is a condition on a goal or a conjunction
|
||||||
of conditions, with each element separated by commas. Each condition is
|
of conditions, with each element separated by commas. Each condition is
|
||||||
of the form `predname( _C1_,..., _CN_)`, where _N_ is the
|
of the form `predname( _C1_,..., _CN_)`, where _N_ is the
|
||||||
arity of the goal, and each _CI_ is of the form `-`, if the
|
arity of the goal, and each _CI_ is of the form `-`, if the
|
||||||
argument must suspend until the first such variable is bound, or
|
argument must suspend until the first such variable is bound, or
|
||||||
`?`, otherwise.
|
`?`, otherwise.
|
||||||
|
|
||||||
+ wait/1
|
+ wait/1
|
||||||
The argument to `wait/1` is a predicate descriptor or a conjunction
|
The argument to `wait/1` is a predicate descriptor or a conjunction
|
||||||
of these predicates. These predicates will suspend until their first
|
of these predicates. These predicates will suspend until their first
|
||||||
argument is bound.
|
argument is bound.
|
||||||
|
|
||||||
|
|
||||||
The following primitives can be used:
|
The following primitives can be used:
|
||||||
|
|
||||||
- freeze/2
|
- freeze/2
|
||||||
|
|
||||||
- dif/2
|
- dif/2
|
||||||
|
|
||||||
- when/2
|
- when/2
|
||||||
|
|
||||||
- frozen/2
|
- frozen/2
|
||||||
|
|
||||||
|
|
||||||
|
@}
|
||||||
|
|
||||||
|
@}
|
||||||
|
@ -1,34 +1,25 @@
|
|||||||
Extensions to core Prolog. {#extensions}
|
@defgroup extensions Extensions to core Prolog.
|
||||||
=========================
|
|
||||||
|
@{
|
||||||
|
|
||||||
|
|
||||||
YAP includes a number of extensions over the original Prolog
|
YAP includes a number of extensions over the original Prolog
|
||||||
language. Next, we discuss how to use the most important ones.
|
language. Next, we discuss how to use the most important ones.
|
||||||
|
|
||||||
+ @ref Rational_Trees
|
+ @ref Rational_Trees
|
||||||
|
|
||||||
+ @ref AttributedVariables
|
+ @ref AttributedVariables
|
||||||
|
|
||||||
+ @ref DepthLimited
|
+ @ref DepthLimited
|
||||||
|
|
||||||
+ @ref Tabling
|
+ @ref Tabling
|
||||||
|
|
||||||
+ @ref Threads
|
+ @ref Threads
|
||||||
|
|
||||||
+ @ref Profiling
|
+ @ref Profiling
|
||||||
|
|
||||||
+ @ref YAPArrays
|
+ @ref YAPArrays
|
||||||
|
|
||||||
+ @ref Parallelism
|
|
||||||
|
|
||||||
In the description of the arguments of predicates the following
|
|
||||||
notation will be used:
|
|
||||||
|
|
||||||
+ a preceding plus sign will denote an argument as an "input
|
|
||||||
argument": the argument is read, not written, and it cannot be a free
|
|
||||||
variable at the time of the call.
|
|
||||||
|
|
||||||
+ a preceding minus sign will denote an "output argument";
|
|
||||||
|
|
||||||
+ an argument with no preceding symbol can be used in both ways.
|
|
||||||
|
|
||||||
|
+ @ref Parallelism
|
||||||
|
|
||||||
|
@}
|
||||||
|
@ -1,27 +1,9 @@
|
|||||||
|
@defgroup library YAP Prolog Library
|
||||||
YAP Prolog Library {#LibraryPage}
|
|
||||||
===================
|
|
||||||
|
|
||||||
|
|
||||||
YAP provides a collection of Prolog utilities, that extend core Prolog
|
|
||||||
with data-structures such as balanced trees and hash tables, extend
|
|
||||||
Input Output, or use the `C`-interface to interact with the
|
|
||||||
Operating System or to implement arrays.
|
|
||||||
|
|
||||||
These programs are stored at the library_directory path (set by the
|
|
||||||
`LIBDIR` variable in the Makefile for YAP).
|
|
||||||
|
|
||||||
The files have different sources. Many were part of the public-domain
|
|
||||||
Edinburgh Prolog library. Other Prolog systems such as SWI-Prolog
|
|
||||||
were kind enough to allow using files from their distributions.
|
|
||||||
|
|
||||||
|
|
||||||
@copydoc library
|
|
||||||
|
|
||||||
|
|
||||||
@{
|
@{
|
||||||
|
|
||||||
@defgroup library The YAP Library
|
the library_directory path (set by the
|
||||||
|
`LIBDIR` variable in the Makefile for YAP). Several files in the
|
||||||
|
library are originally from the public-domain Edinburgh Prolog library.
|
||||||
|
|
||||||
@}
|
@}
|
||||||
|
|
||||||
|
@ -1,10 +1,361 @@
|
|||||||
Programming in YAP {#YAPProgramming}
|
Programming in YAP {#YAPProgramming}
|
||||||
====================
|
====================
|
||||||
|
|
||||||
+ @subpage YAPSyntax
|
+ @ref load_files
|
||||||
|
|
||||||
+ @ref YAPCompilerSettings
|
+ @ref YAPSyntax
|
||||||
|
|
||||||
+ @ref Indexing
|
+ @ref YAPCompilerSettings
|
||||||
|
|
||||||
+ @ref Deb_Interaction
|
+ @ref Indexing
|
||||||
|
|
||||||
|
+ @ref Deb_Interaction
|
||||||
|
|
||||||
|
|
||||||
|
@defgroup load_files Loading and Organizing YAP Programs
|
||||||
|
@{
|
||||||
|
|
||||||
|
We present the main predicates and directives available to load
|
||||||
|
files and to control the Prolog environment.
|
||||||
|
|
||||||
|
@}
|
||||||
|
|
||||||
|
@defgroup YAPModules The YAP Module system
|
||||||
|
|
||||||
|
@{
|
||||||
|
The YAP module system is based on the Quintus/SISCtus module
|
||||||
|
system @cite quintus . In this design, modules are named collections of predicates,
|
||||||
|
and all predicates belong to a single module. By default, predicates are only
|
||||||
|
visible within a module, or _private_ to that module. The module
|
||||||
|
may also define a list of predicates that are
|
||||||
|
_exported_, that is, visible to other modules.
|
||||||
|
|
||||||
|
The main predicates in the module system are:
|
||||||
|
|
||||||
|
* module/2 associates a source file to a module. It has two arguments: the name of the new module, and a list of predicates exported by the module.
|
||||||
|
|
||||||
|
* use_module/1 and use_module/2 can be used to load a module. They take as first argument the source file for the module. Whereas use_module/1 loads all exported predicates, use_module/2 only takes the ones given by the second argument.
|
||||||
|
|
||||||
|
YAP pre-defines a number of modules. Most system predicates belong to
|
||||||
|
the module `prolog`. Predicates from the module `prolog` are
|
||||||
|
automatically visible to every module. The `system` module was
|
||||||
|
introduced for SWI-Prolog compatibility, and in YAP mostly acts as an
|
||||||
|
alias to `prolog`. The `user` module is also visible to all other modules.
|
||||||
|
|
||||||
|
The YAP engine is always associated to a module, the current <em>source
|
||||||
|
module</em> or <em>type-in module</em>. By default, all predicates
|
||||||
|
read-in and all calls to a goal will be made to predicates visible to
|
||||||
|
the current source module, Initially, the source module for YAP is the
|
||||||
|
module `user`. Thus Prolog programs that do not define modules will
|
||||||
|
operate within the `user` module. In this case, all predicates will be
|
||||||
|
visible to all source files.
|
||||||
|
|
||||||
|
YAP includes a number of libraries and packages, most of them
|
||||||
|
defining their own modules. Note that there is no system mechanism to
|
||||||
|
avoid clashes between module names, so it is up to the programmer to
|
||||||
|
carefully choose the names for her own program modules.
|
||||||
|
|
||||||
|
The main mechanism to change the current type-in module is by using
|
||||||
|
the module/2 declaration.This declaration sets the source module when
|
||||||
|
it starts consulting a file, and resets it at the end. One can set
|
||||||
|
the type-in module permanently by using the built-in `module/1`.
|
||||||
|
|
||||||
|
### Explicit Naming {#ExplicitNaming}
|
||||||
|
|
||||||
|
The module system allows one to _explicitly_ specify the source mode for
|
||||||
|
a clause by prefixing a clause with its module, say:
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.prolog}
|
||||||
|
user:(a :- b).
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
it is also possible to type
|
||||||
|
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.prolog}
|
||||||
|
|
||||||
|
user:a :- user:b.
|
||||||
|
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
both formulations describe the same clause, independently of the
|
||||||
|
current type-in module.
|
||||||
|
|
||||||
|
In fact, it is sufficient to specify the source mode for the clause's
|
||||||
|
head:
|
||||||
|
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.prolog}
|
||||||
|
user:a :- b.
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
if the current type-in module is `m`, the clause could also be written as:
|
||||||
|
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.prolog}
|
||||||
|
user:a :- m:b.
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
The compiler rewrites the source clauses to ensure that explicit calls
|
||||||
|
are respected, and that implicit calls are made to the current source
|
||||||
|
module.
|
||||||
|
|
||||||
|
A goal should refer to a predicate visible within the current type-in
|
||||||
|
module. Thus, if a goal appears in a text file with a module
|
||||||
|
declaration, the goal refers to that module's context (but see the
|
||||||
|
initialization/1 directive for more details).
|
||||||
|
|
||||||
|
Again, one can override this rule by prefixing a goal with a module to
|
||||||
|
be consulted. The following query:
|
||||||
|
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.prolog}
|
||||||
|
?- nasa:launch(apollo,13).
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
invokes the goal `launch(apollo,13)` as if the current source
|
||||||
|
module was `nasa`.
|
||||||
|
|
||||||
|
YAP and other Prolog systems allow the module prefix to see all
|
||||||
|
predicates visible in the module, including predicates private to the
|
||||||
|
module. This rule allows maximum flexibility, but it also breaks
|
||||||
|
encapsulation and should be used with care. The ciao language proposes
|
||||||
|
a different approach to this problem, see \cite DBLP:conf/cl/GrasH00 .
|
||||||
|
|
||||||
|
Modules are not always associated with a source-file. They
|
||||||
|
may range over several files, by using the
|
||||||
|
`include`directive. Moreover, they may not be associated to any source
|
||||||
|
file. As an example,
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.prolog}
|
||||||
|
?- assert( nasa:launch(apollo,13) ).
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
will create a module `nasa`, if does not already exist. In fact it is
|
||||||
|
sufficient to call a predicate from a module to implicitly create the
|
||||||
|
module. Hence after this call:
|
||||||
|
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.prolog}
|
||||||
|
?- nasa:launch(apollo,13).
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
there will be a `nasa`module in the system, even if nasa:launch/2 is
|
||||||
|
not at all defined.
|
||||||
|
|
||||||
|
\pred use_module( +Files ) is directive
|
||||||
|
loads a module file
|
||||||
|
|
||||||
|
This predicate loads the file specified by _Files_, importing all
|
||||||
|
their public predicates into the current type-in module. It is
|
||||||
|
implemented as if by:
|
||||||
|
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.prolog}
|
||||||
|
use_module(F) :-
|
||||||
|
load_files(F, [if(not_loaded),must_be_module(true)]).
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Notice that _Files_ may be a single file, or a list with a number
|
||||||
|
files. The _Files_ are loaded in YAP only once, even if they have been
|
||||||
|
updated meanwhile. YAP should also verify whether the files actually
|
||||||
|
define modules. Please consult load_files/3 for other options when
|
||||||
|
loading a file.
|
||||||
|
|
||||||
|
Predicate name clashes between two different modules may arise, either
|
||||||
|
when trying to import predicates that are also defined in the current
|
||||||
|
type-in module, or by trying to import the same predicate from two
|
||||||
|
different modules.
|
||||||
|
|
||||||
|
In the first case, the local predicate is considered to have priority
|
||||||
|
and use_module/1 simply gives a warning. As an example, if the file
|
||||||
|
`a.pl` contains:
|
||||||
|
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.prolog}
|
||||||
|
:- module( a, [a/1] ).
|
||||||
|
|
||||||
|
:- use_module(b).
|
||||||
|
|
||||||
|
a(1).
|
||||||
|
a(X) :- b(X).
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
and the file `b.pl` contains:
|
||||||
|
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.prolog}
|
||||||
|
:- module( b, [a/1,b/1] ).
|
||||||
|
|
||||||
|
a(2).
|
||||||
|
|
||||||
|
b(1).
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
YAP will execute as follows:
|
||||||
|
|
||||||
|
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.prolog}
|
||||||
|
?- [a].
|
||||||
|
% consulting .../a.pl...
|
||||||
|
% consulting .../b.pl...
|
||||||
|
% consulted .../b.pl in module b, 0 msec 0 bytes
|
||||||
|
% consulted .../a.pl in module a, 1 msec 0 bytes
|
||||||
|
true.
|
||||||
|
?- a(X).
|
||||||
|
X = 1 ? ;
|
||||||
|
X = 1.
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
The example shows that the query `a(X)`has a single answer, the one
|
||||||
|
defined in `a.pl`. Calls to `a(X)`succeed in the top-level, because
|
||||||
|
the module `a` was loaded into `user`. On the other hand, `b(X)`is not
|
||||||
|
exported by `a.pl`, and is not available to calls, although it can be
|
||||||
|
accessed as a predicate in the module 'a' by using the `:` operator.
|
||||||
|
|
||||||
|
Next, consider the three files `c.pl`, `d1.pl`, and `d2.pl`:
|
||||||
|
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.prolog}
|
||||||
|
% c.pl
|
||||||
|
:- module( c, [a/1] ).
|
||||||
|
|
||||||
|
:- use_module([d1, d2]).
|
||||||
|
|
||||||
|
a(X) :-
|
||||||
|
b(X).
|
||||||
|
a(X) :-
|
||||||
|
c(X).
|
||||||
|
a(X) :-
|
||||||
|
d(X).
|
||||||
|
|
||||||
|
% d1.pl
|
||||||
|
:- module( d1, [b/1,c/1] ).
|
||||||
|
|
||||||
|
b(2).
|
||||||
|
c(3).
|
||||||
|
|
||||||
|
|
||||||
|
% d2.pl
|
||||||
|
:- module( d2, [b/1,d/1] ).
|
||||||
|
|
||||||
|
b(1).
|
||||||
|
d(4).
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
The result is as follows:
|
||||||
|
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.prolog}
|
||||||
|
./yap -l c
|
||||||
|
YAP 6.3.4 (x86_64-darwin13.3.0): Tue Jul 15 10:42:11 CDT 2014
|
||||||
|
|
||||||
|
ERROR!!
|
||||||
|
at line 3 in o/d2.pl,
|
||||||
|
PERMISSION ERROR- loading .../c.pl: modules d1 and d2 both define b/1
|
||||||
|
?- a(X).
|
||||||
|
X = 2 ? ;
|
||||||
|
ERROR!!
|
||||||
|
EXISTENCE ERROR- procedure c/1 is undefined, called from context prolog:$user_call/2
|
||||||
|
Goal was c:c(_131290)
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
The state of the module system after this error is undefined.
|
||||||
|
|
||||||
|
### Built-In predicates {#ModuleBuiltins)
|
||||||
|
|
||||||
|
@\pred module(+ M:atom,+ L:list ) is directive
|
||||||
|
the current file defines module _M_ with exports _L_. The list may include
|
||||||
|
|
||||||
|
+ predicate indicators
|
||||||
|
|
||||||
|
+ operator definitions that look like calls to op/3.
|
||||||
|
|
||||||
|
The list _L_ may include predicates imported from other modules. If
|
||||||
|
you want to fully reexport a module, or a sub-set, also consider reexport/1.
|
||||||
|
|
||||||
|
Similar to module/2, this directive defines the file where it
|
||||||
|
appears in as a module file; it must be the first declaration in the file.
|
||||||
|
_M_ must be an atom specifying the module name; _L_ must be a
|
||||||
|
list containing the module's public predicates specification, in the
|
||||||
|
form `[predicate_name/arity,...]`.
|
||||||
|
|
||||||
|
The last argument _Options_ must be a list of options, which can be:
|
||||||
|
+ <b>filename</b>
|
||||||
|
the filename for a module to import into the current module.
|
||||||
|
|
||||||
|
+ <b>library( +File )</b>
|
||||||
|
a library file to import into the current module.
|
||||||
|
|
||||||
|
+ <b>hide( +Opt)</b>
|
||||||
|
if _Opt_ is `false`, keep source code for current module, if `true`, disable.
|
||||||
|
|
||||||
|
+ <b>export(+PredicateIndicator )</b>
|
||||||
|
Add predicates to the public list of the context module. This implies
|
||||||
|
the predicate will be imported into another module if this module
|
||||||
|
is imported with use_module/1 and use_module/2.
|
||||||
|
|
||||||
|
+ <b>export_list(? _Mod_,? _ListOfPredicateIndicator_)</b>
|
||||||
|
The list _ListOfPredicateIndicator_ contains all predicates
|
||||||
|
exported by module _Mod_
|
||||||
|
|
||||||
|
Note that predicates are normally exported using the directive
|
||||||
|
`module/2`. The `export/1` argumwnt is meant to allow export from
|
||||||
|
dynamically created modules. The directive argument may also be a list
|
||||||
|
of predicates.
|
||||||
|
|
||||||
|
@pred use_module(+Files, +Imports)
|
||||||
|
loads a module file but only imports the named predicates
|
||||||
|
|
||||||
|
|
||||||
|
This predicate loads the file specified by _Files_, importing their
|
||||||
|
public predicates specified by _Imports_ into the current type-in
|
||||||
|
module. It is implemented as if by:
|
||||||
|
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.prolog}
|
||||||
|
use_module(Files, Imports) :-
|
||||||
|
load_files(Files, [if(not_loaded),must_be_module(true),imports(Imports)]).
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
The _Imports_ argument may be use to specify which predicates one
|
||||||
|
wants to load. It can also be used to give the predicates a different name. As an example,
|
||||||
|
the graphs library is implemented on top of the red-black trees library, and some predicates are just aliases:
|
||||||
|
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.prolog}
|
||||||
|
:- use_module(library(rbtrees), [
|
||||||
|
rb_min/3 as min_assoc,
|
||||||
|
rb_max/3 as max_assoc,
|
||||||
|
|
||||||
|
...]).
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Unfortunately it is still not possible to change argument order.
|
||||||
|
|
||||||
|
|
||||||
|
\pred module(+ M:atom,+ L:list ) is directive
|
||||||
|
the current file defines module _M_ with exports _L_. The list may include
|
||||||
|
|
||||||
|
+ predicate indicators
|
||||||
|
|
||||||
|
+ operator definitions that look like calls to op/3.
|
||||||
|
|
||||||
|
The list _L_ may include predicates imported from other modules. If
|
||||||
|
you want to fully reexport a module, or a sub-set, also consider reexport/1.
|
||||||
|
|
||||||
|
Similar to module/2, this directive defines the file where it
|
||||||
|
appears in as a module file; it must be the first declaration in the file.
|
||||||
|
_M_ must be an atom specifying the module name; _L_ must be a
|
||||||
|
list containing the module's public predicates specification, in the
|
||||||
|
form `[predicate_name/arity,...]`.
|
||||||
|
|
||||||
|
The last argument _Options_ must be a list of options, which can be:
|
||||||
|
+<b>filename</b>
|
||||||
|
the filename for a module to import into the current module.
|
||||||
|
|
||||||
|
+ <b>library( +File )</b>
|
||||||
|
a library file to import into the current module.
|
||||||
|
|
||||||
|
+ <b>hide( +Opt)</b>
|
||||||
|
if _Opt_ is `false`, keep source code for current module, if `true`, disable.
|
||||||
|
|
||||||
|
+ <b>export(+PredicateIndicator )</b>
|
||||||
|
Add predicates to the public list of the context module. This implies
|
||||||
|
the predicate will be imported into another module if this module
|
||||||
|
is imported with use_module/1 and use_module/2.
|
||||||
|
|
||||||
|
+ <b>export_list(? _Mod_,? _ListOfPredicateIndicator_)</b>
|
||||||
|
The list _ListOfPredicateIndicator_ contains all predicates
|
||||||
|
exported by module _Mod_
|
||||||
|
|
||||||
|
Note that predicates are normally exported using the directive
|
||||||
|
`module/2`. The `export/1` argument is meant to allow export from
|
||||||
|
dynamically created modules. The directive argument may also be a list
|
||||||
|
of predicates.
|
||||||
|
|
||||||
|
@}
|
||||||
|
@ -7,8 +7,8 @@ We next describe how to invoke YAP in Unix systems.
|
|||||||
|
|
||||||
[TOC]
|
[TOC]
|
||||||
|
|
||||||
### Running YAP Interactively {#Running_YAP_Interactively}
|
Running YAP Interactively {#Running_YAP_Interactively}
|
||||||
|
--------------------------
|
||||||
|
|
||||||
Most often you will want to use YAP in interactive mode. Assuming that
|
Most often you will want to use YAP in interactive mode. Assuming that
|
||||||
YAP is in the user's search path, the top-level can be invoked under
|
YAP is in the user's search path, the top-level can be invoked under
|
||||||
@ -54,7 +54,7 @@ boot code is in Prolog file _BOOT_FILE_. The filename must define
|
|||||||
the predicate `'$live'/0`.
|
the predicate `'$live'/0`.
|
||||||
+ -c <tt>IP_HOST</tt> <tt>port</tt>
|
+ -c <tt>IP_HOST</tt> <tt>port</tt>
|
||||||
connect standard streams to host <tt>IP_HOST</tt> at port <tt>port</tt>
|
connect standard streams to host <tt>IP_HOST</tt> at port <tt>port</tt>
|
||||||
+ filename
|
+ filename
|
||||||
restore state saved in the given file
|
restore state saved in the given file
|
||||||
+ -f
|
+ -f
|
||||||
do not consult initial files
|
do not consult initial files
|
||||||
@ -67,38 +67,28 @@ through the unix/1 built-in predicate.
|
|||||||
|
|
||||||
Note that YAP will output an error message on the following conditions:
|
Note that YAP will output an error message on the following conditions:
|
||||||
|
|
||||||
+
|
+ a file name was given but the file does not exist or is not a saved
|
||||||
a file name was given but the file does not exist or is not a saved
|
|
||||||
YAP state;
|
YAP state;
|
||||||
|
|
||||||
+
|
+ the necessary amount of memory could not be allocated;
|
||||||
the necessary amount of memory could not be allocated;
|
|
||||||
|
|
||||||
+
|
+ the allocated memory is not enough to restore the state.
|
||||||
the allocated memory is not enough to restore the state.
|
|
||||||
|
|
||||||
|
When restoring a saved state, YAP will allocate the same amount of memory as that in use when the state was saved, unless a different amount is specified by flags in the command line. By default, YAP restores the file startup.yss from the current directory or from the YAP library.
|
||||||
|
|
||||||
When restoring a saved state, YAP will allocate the
|
+ YAP usually boots from a saved state. The saved state will use the default
|
||||||
same amount of memory as that in use when the state was saved, unless a
|
|
||||||
different amount is specified by flags in the command line. By default,
|
|
||||||
YAP restores the file startup.yss from the current directory or from
|
|
||||||
the YAP library.
|
|
||||||
|
|
||||||
+
|
|
||||||
YAP usually boots from a saved state. The saved state will use the default
|
|
||||||
installation directory to search for the YAP binary unless you define
|
installation directory to search for the YAP binary unless you define
|
||||||
the environment variable YAPBINDIR.
|
the environment variable YAPBINDIR.
|
||||||
|
|
||||||
+
|
+ YAP always tries to find saved states from the current directory
|
||||||
YAP always tries to find saved states from the current directory
|
first. If it cannot it will use the environment variable YAPLIBDIR,
|
||||||
first. If it cannot it will use the environment variable YAPLIBDIR, if
|
if
|
||||||
defined, or search the default library directory.
|
defined, or search the default library directory.
|
||||||
|
|
||||||
|
+ YAP will try to find library files from the YAPSHAREDIR/library directory.
|
||||||
|
|
||||||
YAP will try to find library files from the YAPSHAREDIR/library
|
Running Prolog Files {#Running_Prolog_Files}
|
||||||
directory.
|
--------------------
|
||||||
|
|
||||||
## Running Prolog Files {#Running_Prolog_Files}
|
|
||||||
|
|
||||||
YAP can also be used to run Prolog files as scripts, at least in
|
YAP can also be used to run Prolog files as scripts, at least in
|
||||||
Unix-like environments. A simple example is shown next (do not forget
|
Unix-like environments. A simple example is shown next (do not forget
|
||||||
|
@ -17,13 +17,11 @@ Porto.
|
|||||||
The manual is organised as follows:
|
The manual is organised as follows:
|
||||||
|
|
||||||
|
|
||||||
+ @subpage INSTALL
|
+ @ref INSTALL
|
||||||
|
|
||||||
+ @subpage run
|
+ @ref run
|
||||||
|
|
||||||
+ @subpage load_files
|
+ @ref builtins
|
||||||
|
|
||||||
+ @subpage builtins
|
|
||||||
|
|
||||||
+ @subpage extensions
|
+ @subpage extensions
|
||||||
|
|
||||||
@ -60,6 +58,40 @@ Jan Wielemaker. We would also like to gratefully
|
|||||||
acknowledge the contributions from Ashwin Srinivasian.
|
acknowledge the contributions from Ashwin Srinivasian.
|
||||||
|
|
||||||
|
|
||||||
|
@page Library YAP Library
|
||||||
|
|
||||||
|
|
||||||
|
the library_directory path (set by the
|
||||||
|
`LIBDIR` variable in the Makefile for YAP). Several files in the
|
||||||
|
library are originally from the public-domain Edinburgh Prolog library.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
@page Extensions YAP Extensions
|
||||||
|
|
||||||
|
YAP includes a number of extensions over the original Prolog
|
||||||
|
language.
|
||||||
|
|
||||||
|
+ @subpage attributes.md
|
||||||
|
|
||||||
|
+ @ref Rational_Trees
|
||||||
|
|
||||||
|
+ @ref CohYroutining
|
||||||
|
|
||||||
|
+ @ref DepthLimited
|
||||||
|
|
||||||
|
+ @ref Tabling
|
||||||
|
|
||||||
|
+ @ref Threads
|
||||||
|
|
||||||
|
+ @ref Profiling
|
||||||
|
|
||||||
|
+ @ref YAPArrays
|
||||||
|
|
||||||
|
+ @ref Parallelism
|
||||||
|
|
||||||
|
|
||||||
|
@page YAPProgramming Programming in YAP
|
||||||
|
|
||||||
|
|
||||||
|
@page packages Packages for YAP
|
||||||
|
Reference in New Issue
Block a user