diogo/yap-6.3
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docsc

Browse Source
This commit is contained in:
Vitor Santos Costa
2016-11-16 17:17:33 -06:00
parent 56905d86ae
commit 8d1cc35a8a
36 changed files with 1523 additions and 2164 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
docs/Doxyfile
View File

@@ -785,9 +785,8 @@ INPUT = /Users/vsc/git/yap-6.3/pl \
/Users/vsc/git/yap-6.3/library \
/Users/vsc/git/yap-6.3/packages \
/Users/vsc/git/yap-6.3/swi/library \
/Users/vsc/git/yap-6.3/docs/yap.md \
/Users/vsc/git/yap-6.3/docs/chr.md \
/Users/vsc/git/yap-6.3/docs/clpqr.md \
/Users/vsc/git/yap-6.3/docs/*.md \
/Users/vsc/git/yap-6.3/*.md \
# This tag can be used to specify the character encoding of the source files
@@ -937,7 +936,7 @@ FILTER_SOURCE_PATTERNS =
# (index.html). This can be useful if you have a project on for instance GitHub
# and want to reuse the introduction page also for the doxygen output.
USE_MDFILE_AS_MAINPAGE =
USE_MDFILE_AS_MAINPAGE =
#---------------------------------------------------------------------------
# Configuration options related to source browsing

5
docs/Doxyfile.in
View File

@@ -785,9 +785,8 @@ INPUT = @PROJECT_SOURCE_DIR@/pl \
@PROJECT_SOURCE_DIR@/library \
@PROJECT_SOURCE_DIR@/packages \
@PROJECT_SOURCE_DIR@/swi/library \
@PROJECT_SOURCE_DIR@/docs/yap.md \
@PROJECT_SOURCE_DIR@/docs/chr.md \
@PROJECT_SOURCE_DIR@/docs/clpqr.md \
@PROJECT_SOURCE_DIR@/docs/*.md \
@PROJECT_SOURCE_DIR@/*.md
# This tag can be used to specify the character encoding of the source files

31
docs/builtins.md
View File

@@ -0,0 +1,31 @@
YAP Built-ins {#builtins}
=================
This chapter describes the core predicates that control the execution of
Prolog programs, provide fundamental functionality such as termm manipulation or arithmetic, and support interaction with external
resources, Many of the predicates described here have been standardised by the ISO. The standartised subset of Proloh also known as ISO-Prolog.
In the description of the arguments of functors the following notation
will be used:
+ a preceding plus sign will denote an argument as an "input
argument" - 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 YAPControl
+ @ref Arithmetic
+ @ref YAPChars
+ @ref YAP_Terms
+ @ref InputOutput
+ @ref AbsoluteFileName
+ @ref YAPOS
+ @ref Internal_Database
+ @ref Sets

532
docs/chr.md
View File

@@ -1,532 +0,0 @@
CHR: Constraint Handling Rules {#chr}
==============================
@ingroup packages
This chapter is written by Tom Schrijvers, K.U. Leuven for the hProlog
system. Adjusted by Jan Wielemaker to fit the SWI-Prolog documentation
infrastructure and remove hProlog specific references.
The CHR system of SWI-Prolog is the K.U.Leuven CHR system. The
runtime environment is written by Christian Holzbaur and Tom
Schrijvers while the compiler is written by Tom Schrijvers. Both are
integrated with SWI-Prolog and licenced under compatible conditions
with permission from the authors. Porting and maintenance on YAP is
the entire responsability of Vítor Santos Costa.
The main reference for SWI-Prolog's CHR system is:
+ T. Schrijvers, and B. Demoen, <em>The K.U.Leuven CHR System: Implementation and Application</em>, First Workshop on Constraint Handling Rules: Selected
Contributions (Fruwirth, T. and Meister, M., eds.), pp. 1--5, 2004.
# Introduction
Constraint Handling Rules (CHR) is a committed-choice bottom-up language
embedded in Prolog. It is designed for writing constraint solvers and is
particularily useful for providing application-specific constraints.
It has been used in many kinds of applications, like scheduling,
model checking, abduction, type checking among many others.
CHR has previously been implemented in other Prolog systems (SICStus,
Eclipse, Yap), Haskell and Java. This CHR system is based on the
compilation scheme and runtime environment of CHR in SICStus.
In this documentation we restrict ourselves to giving a short overview
of CHR in general and mainly focus on elements specific to this
implementation. For a more thorough review of CHR we refer the reader to
[Freuhwirth:98]. More background on CHR can be found at the CHR web site.
### Syntax and Semantics
We present informally the syntax and semantics of CHR.
#### CHR Syntax
The syntax of CHR rules in hProlog is the following:
~~~~~
rules --> rule, rules.
rules --> [].
rule --> name, actual_rule, pragma, [atom(`.`)].
name --> atom, [atom(`@`)].
name --> [].
actual_rule --> simplification_rule.
actual_rule --> propagation_rule.
actual_rule --> simpagation_rule.
simplification_rule --> constraints, [atom(`<=>`)], guard, body.
propagation_rule --> constraints, [atom(`==>`)], guard, body.
simpagation_rule --> constraints, [atom(`\`)], constraints, [atom(`<=>`)],
guard, body.
constraints --> constraint, constraint_id.
constraints --> constraint, [atom(`,`)], constraints.
constraint --> compound_term.
constraint_id --> [].
constraint_id --> [atom(`#`)], variable.
guard --> [].
guard --> goal, [atom(`|`)].
body --> goal.
pragma --> [].
pragma --> [atom(`pragma`)], actual_pragmas.
actual_pragmas --> actual_pragma.
actual_pragmas --> actual_pragma, [atom(`,`)], actual_pragmas.
actual_pragma --> [atom(`passive(`)], variable, [atom(`)`)].
~~~~~
Additional syntax-related terminology:
+ *head:* the constraints in an `actual_rule` before
the arrow (either `<=>` or `==>`)
#### Semantics Semantics
In this subsection the operational semantics of CHR in Prolog are presented
informally. They do not differ essentially from other CHR systems.
When a constraint is called, it is considered an active constraint and
the system will try to apply the rules to it. Rules are tried and executed
sequentially in the order they are written.
A rule is conceptually tried for an active constraint in the following
way. The active constraint is matched with a constraint in the head of
the rule. If more constraints appear in the head they are looked for
among the suspended constraints, which are called passive constraints in
this context. If the necessary passive constraints can be found and all
match with the head of the rule and the guard of the rule succeeds, then
the rule is committed and the body of the rule executed. If not all the
necessary passive constraint can be found, the matching fails or the
guard fails, then the body is not executed and the process of trying and
executing simply continues with the following rules. If for a rule,
there are multiple constraints in the head, the active constraint will
try the rule sequentially multiple times, each time trying to match with
another constraint.
This process ends either when the active constraint disappears, i.e. it
is removed by some rule, or after the last rule has been processed. In
the latter case the active constraint becomes suspended.
A suspended constraint is eligible as a passive constraint for an active
constraint. The other way it may interact again with the rules, is when
a variable appearing in the constraint becomes bound to either a nonvariable
or another variable involved in one or more constraints. In that case the
constraint is triggered, i.e. it becomes an active constraint and all
the rules are tried.
### Rules
There are three different kinds of rules, each with their specific semantics:
+ simplification
The simplification rule removes the constraints in its head and calls its body.
+ propagation
The propagation rule calls its body exactly once for the constraints in
its head.
+ simpagation
The simpagation rule removes the constraints in its head after the
`\` and then calls its body. It is an optimization of
simplification rules of the form: \[constraints_1, constraints_2 <=>
constraints_1, body \] Namely, in the simpagation form:
~~~~~
constraints1 \ constraints2 <=> body
~~~~~
_constraints1_
constraints are not called in the body.
#### Rule Names
Naming a rule is optional and has no semantical meaning. It only functions
as documentation for the programmer.
### Pragmas
The semantics of the pragmas are:
+ passive(Identifier)
The constraint in the head of a rule _Identifier_ can only act as a
passive constraint in that rule.
Additional pragmas may be released in the future.
### CHR_Options Options
It is possible to specify options that apply to all the CHR rules in the module.
Options are specified with the `option/2` declaration:
~~~~~
option(Option,Value).
~~~~~
Available options are:
+ check_guard_bindings
This option controls whether guards should be checked for illegal
variable bindings or not. Possible values for this option are
`on`, to enable the checks, and `off`, to disable the
checks.
+ optimize
This is an experimental option controlling the degree of optimization.
Possible values are `full`, to enable all available
optimizations, and `off` (default), to disable all optimizations.
The default is derived from the SWI-Prolog flag `optimise`, where
`true` is mapped to `full`. Therefore the commandline
option `-O` provides full CHR optimization.
If optimization is enabled, debugging should be disabled.
+ debug
This options enables or disables the possibility to debug the CHR code.
Possible values are `on` (default) and `off`. See
`debugging` for more details on debugging. The default is
derived from the prolog flag `generate_debug_info`, which
is `true` by default. See `-nodebug`.
If debugging is enabled, optimization should be disabled.
+ mode
This option specifies the mode for a particular constraint. The
value is a term with functor and arity equal to that of a constraint.
The arguments can be one of `-`, `+` or `?`.
The latter is the default. The meaning is the following:
+ -
The corresponding argument of every occurrence
of the constraint is always unbound.
+ +
The corresponding argument of every occurrence
of the constraint is always ground.
+ ?
The corresponding argument of every occurrence
of the constraint can have any instantiation, which may change
over time. This is the default value.
The declaration is used by the compiler for various optimizations.
Note that it is up to the user the ensure that the mode declaration
is correct with respect to the use of the constraint.
This option may occur once for each constraint.
+ type_declaration
This option specifies the argument types for a particular constraint. The
value is a term with functor and arity equal to that of a constraint.
The arguments can be a user-defined type or one of
the built-in types:
+ int
The corresponding argument of every occurrence
of the constraint is an integer number.
+ float
...{} a floating point number.
+ number
...{} a number.
+ natural
...{} a positive integer.
+ any
The corresponding argument of every occurrence
of the constraint can have any type. This is the default value.
Currently, type declarations are only used to improve certain
optimizations (guard simplification, occurrence subsumption, ...{}).
+ type_definition
This option defines a new user-defined type which can be used in
type declarations. The value is a term of the form
`type(` _name_`,` _list_`)`, where
_name_ is a term and _list_ is a list of alternatives.
Variables can be used to define generic types. Recursive definitions
are allowed. Examples are
~~~~~
type(bool,[true,false]).
type(complex_number,[float + float * i]).
type(binary_tree(T),[ leaf(T) | node(binary_tree(T),binary_tree(T)) ]).
type(list(T),[ [] | [T | list(T)]).
~~~~~
The mode, type_declaration and type_definition options are provided
for backward compatibility. The new syntax is described below.
### CHR in Prolog Programs
The CHR constraints defined in a particulary chr file are
associated with a module. The default module is `user`. One should
never load different chr files with the same CHR module name.
#### Constraint Declarations
Every constraint used in CHR rules has to be declared.
There are two ways to do this. The old style is as follows:
~~~~~
option(type_definition,type(list(T),[ [] , [T|list(T)] ]).
option(mode,foo(+,?)).
option(type_declaration,foo(list(int),float)).
:- constraints foo/2, bar/0.
~~~~~
The new style is as follows:
~~~~~
:- chr_type list(T) ---> [] ; [T|list(T)].
:- constraints foo(+list(int),?float), bar.
~~~~~
#### Compilation
The
SWI-Prolog CHR compiler exploits term_expansion/2 rules to translate
the constraint handling rules to plain Prolog. These rules are loaded
from the library chr. They are activated if the compiled file
has the chr extension or after finding a declaration of the
format below.
~~~~~
:- constraints ...
~~~~~
It is adviced to define CHR rules in a module file, where the module
declaration is immediately followed by including the chr
library as examplified below:
~~~~~
:- module(zebra, [ zebra/0 ]).
:- use_module(library(chr)).
:- constraints ...
~~~~~
Using this style CHR rules can be defined in ordinary Prolog
pl files and the operator definitions required by CHR do not
leak into modules where they might cause conflicts.
#### CHR Debugging
The CHR debugging facilities are currently rather limited. Only tracing
is currently available. To use the CHR debugging facilities for a CHR
file it must be compiled for debugging. Generating debug info is
controlled by the CHR option debug, whose default is derived
from the SWI-Prolog flag `generate_debug_info`. Therefore debug
info is provided unless the `-nodebug` is used.
#### Ports
vFor CHR constraints the four standard ports are defined:
+ call
A new constraint is called and becomes active.
+ exit
An active constraint exits: it has either been inserted in the store after
trying all rules or has been removed from the constraint store.
+ fail
An active constraint fails.
+ redo
An active constraint starts looking for an alternative solution.
In addition to the above ports, CHR constraints have five additional
ports:
+ wake
A suspended constraint is woken and becomes active.
+ insert
An active constraint has tried all rules and is suspended in
the constraint store.
+ remove
An active or passive constraint is removed from the constraint
store, if it had been inserted.
+ try
An active constraints tries a rule with possibly
some passive constraints. The try port is entered
just before committing to the rule.
+ apply
An active constraints commits to a rule with possibly
some passive constraints. The apply port is entered
just after committing to the rule.
#### Tracing
Tracing is enabled with the chr_trace/0 predicate
and disabled with the chr_notrace/0 predicate.
When enabled the tracer will step through the `call`,
`exit`, `fail`, `wake` and `apply` ports,
accepting debug commands, and simply write out the other ports.
The following debug commans are currently supported:
~~~~~
CHR debug options:
<cr> creep c creep
s skip
g ancestors
n nodebug
b break
a abort
f fail
? help h help
~~~~~
Their meaning is:
+ creep
Step to the next port.
+ skip
Skip to exit port of this call or wake port.
+ ancestors
Print list of ancestor call and wake ports.
+ nodebug
Disable the tracer.
+ break
Enter a recursive Prolog toplevel. See break/0.
+ abort
Exit to the toplevel. See abort/0.
+ fail
Insert failure in execution.
+ help
Print the above available debug options.
#### CHR Debugging Predicates
The chr module contains several predicates that allow
inspecting and printing the content of the constraint store.
+ chr_trace
Activate the CHR tracer. By default the CHR tracer is activated and
deactivated automatically by the Prolog predicates trace/0 and
notrace/0.
### CHR_Examples Examples
Here are two example constraint solvers written in CHR.
+
The program below defines a solver with one constraint,
`leq/2`, which is a less-than-or-equal constraint.
~~~~~
:- module(leq,[cycle/3, leq/2]).
:- use_module(library(chr)).
:- constraints leq/2.
reflexivity @ leq(X,X) <=> true.
antisymmetry @ leq(X,Y), leq(Y,X) <=> X = Y.
idempotence @ leq(X,Y) \ leq(X,Y) <=> true.
transitivity @ leq(X,Y), leq(Y,Z) ==> leq(X,Z).
cycle(X,Y,Z):-
leq(X,Y),
leq(Y,Z),
leq(Z,X).
~~~~~
+
The program below implements a simple finite domain
constraint solver.
~~~~~
:- module(dom,[dom/2]).
:- use_module(library(chr)).
:- constraints dom/2.
dom(X,[]) <=> fail.
dom(X,[Y]) <=> X = Y.
dom(X,L1), dom(X,L2) <=> intersection(L1,L2,L3), dom(X,L3).
intersection([],_,[]).
intersection([H|T],L2,[H|L3]) :-
member(H,L2), !,
intersection(T,L2,L3).
intersection([_|T],L2,L3) :-
intersection(T,L2,L3).
~~~~~
### Compatibility with SICStus CHR
There are small differences between CHR in SWI-Prolog and newer
YAPs and SICStus and older versions of YAP. Besides differences in
available options and pragmas, the following differences should be
noted:
+ [The handler/1 declaration]
In SICStus every CHR module requires a `handler/1`
declaration declaring a unique handler name. This declaration is valid
syntax in SWI-Prolog, but will have no effect. A warning will be given
during compilation.
+ [The rules/1 declaration]
In SICStus, for every CHR module it is possible to only enable a subset
of the available rules through the `rules/1` declaration. The
declaration is valid syntax in SWI-Prolog, but has no effect. A
warning is given during compilation.
+ [Sourcefile naming]
SICStus uses a two-step compiler, where chr files are
first translated into pl files. For SWI-Prolog CHR
rules may be defined in a file with any extension.
### Guidelines
In this section we cover several guidelines on how to use CHR to write
constraint solvers and how to do so efficiently.
+ [Set semantics]
The CHR system allows the presence of identical constraints, i.e.
multiple constraints with the same functor, arity and arguments. For
most constraint solvers, this is not desirable: it affects efficiency
and possibly termination. Hence appropriate simpagation rules should be
added of the form:
~~~~~
{constraint \ constraint <=> true}.
~~~~~
+ [Multi-headed rules]
Multi-headed rules are executed more efficiently when the constraints
share one or more variables.
+ [Mode and type declarations]
Provide mode and type declarations to get more efficient program execution.
Make sure to disable debug (`-nodebug`) and enable optimization
(`-O`).

122
docs/clpqr.md
View File

@@ -1,122 +0,0 @@
Constraint Logic Programming over Rationals and Reals {#clpqr}
=====================================================
@ingroup paackages
YAP now uses the CLP(R) package developed by <em>Leslie De Koninck</em>,
K.U. Leuven as part of a thesis with supervisor Bart Demoen and daily
advisor Tom Schrijvers, and distributed with SWI-Prolog.
This CLP(R) system is a port of the CLP(Q,R) system of Sicstus Prolog
and YAP by Christian Holzbaur: Holzbaur C.: OFAI clp(q,r) Manual,
Edition 1.3.3, Austrian Research Institute for Artificial
Intelligence, Vienna, TR-95-09, 1995,
<http://www.ai.univie.ac.at/cgi-bin/tr-online?number+95-09> This
port only contains the part concerning real arithmetics. This manual
is roughly based on the manual of the above mentioned *CLP(QR)*
implementation.
Please note that the clpr library is <em>not</em> an
`autoload` library and therefore this library must be loaded
explicitely before using it:
~~~~~
:- use_module(library(clpr)).
~~~~~
### Solver Predicates {#CLPQR_Solver_Predicates}
The following predicates are provided to work with constraints:
### Syntax of the predicate arguments {#CLPQR_Syntax}
The arguments of the predicates defined in the subsection above are
defined in the following table. Failing to meet the syntax rules will
result in an exception.
~~~~~
<Constraints> ---> <Constraint> \ single constraint \
| <Constraint> , <Constraints> \ conjunction \
| <Constraint> ; <Constraints> \ disjunction \
<Constraint> ---> <Expression> {<} <Expression> \ less than \
| <Expression> {>} <Expression> \ greater than \
| <Expression> {=<} <Expression> \ less or equal \
| {<=}(<Expression>, <Expression>) \ less or equal \
| <Expression> {>=} <Expression> \ greater or equal \
| <Expression> {=\=} <Expression> \ not equal \
| <Expression> =:= <Expression> \ equal \
| <Expression> = <Expression> \ equal \
<Expression> ---> <Variable> \ Prolog variable \
| <Number> \ Prolog number (float, integer) \
| +<Expression> \ unary plus \
| -<Expression> \ unary minus \
| <Expression> + <Expression> \ addition \
| <Expression> - <Expression> \ substraction \
| <Expression> * <Expression> \ multiplication \
| <Expression> / <Expression> \ division \
| abs(<Expression>) \ absolute value \
| sin(<Expression>) \ sine \
| cos(<Expression>) \ cosine \
| tan(<Expression>) \ tangent \
| exp(<Expression>) \ exponent \
| pow(<Expression>) \ exponent \
| <Expression> {^} <Expression> \ exponent \
| min(<Expression>, <Expression>) \ minimum \
| max(<Expression>, <Expression>) \ maximum \
~~~~~
### Use of unification {#CLPQR_Unification}
Instead of using the `{}/1` predicate, you can also use the standard
unification mechanism to store constraints. The following code samples
are equivalent:
+ Unification with a variable
~~~~~
{X =:= Y}
{X = Y}
X = Y
~~~~~
+ Unification with a number
~~~~~
{X =:= 5.0}
{X = 5.0}
X = 5.0
~~~~~
#### Non-Linear Constraints {#CLPQR_NonhYlinear_Constraints}
In this version, non-linear constraints do not get solved until certain
conditions are satisfied. We call these conditions the _isolation_ axioms.
They are given in the following table.
~~~~~
A = B * C when B or C is ground or // A = 5 * C or A = B * 4 \\
A and (B or C) are ground // 20 = 5 * C or 20 = B * 4 \\
A = B / C when C is ground or // A = B / 3
A and B are ground // 4 = 12 / C
X = min(Y,Z) when Y and Z are ground or // X = min(4,3)
X = max(Y,Z) Y and Z are ground // X = max(4,3)
X = abs(Y) Y is ground // X = abs(-7)
X = pow(Y,Z) when X and Y are ground or // 8 = 2 ^ Z
X = exp(Y,Z) X and Z are ground // 8 = Y ^ 3
X = Y ^ Z Y and Z are ground // X = 2 ^ 3
X = sin(Y) when X is ground or // 1 = sin(Y)
X = cos(Y) Y is ground // X = sin(1.5707)
X = tan(Y)
~~~~~

17
docs/download.md
View File

@@ -0,0 +1,17 @@
Downloading YAP {#download}
==============
The latest development version of Yap-6 is yap-6.3.4 and can be
obtained from the repositories
<http://sourceforge.net/p/yap/yap-6.3>
and
<https://github.com/vscosta/yap-6.3>
YAP-6.3.4 does not use modules. Please just use `git clone` to obtain the distribution.
Most of these repositories are basically copies of the original
repositories at the SWI-Prolog site. YAP-6 will work either with or
without these packages.

21
docs/extensions.md
View File

@@ -0,0 +1,21 @@
Extensions to core Prolog. {#extensions}
=========================
YAP includes a number of extensions over the original Prolog
language. Next, we discuss how to use the most important ones.
+ @ref Rational_Trees
+ @ref AttributedVariables
+ @ref DepthLimited
+ @ref Tabling
+ @ref Threads
+ @ref Profiling
+ @ref YAPArrays
+ @ref Parallelism

16
docs/fli.md
View File

@@ -0,0 +1,16 @@
The Foreign Code Interface {#fli}
===========================
YAP provides the user with three facilities for writing
predicates in a language other than Prolog. Under Unix systems,
most language implementations were linkable to `C`, and the first interface exported the YAP machinery to the C language. YAP also implements most of the SWI-Prolog foreign language interface.
This gives portability with a number of SWI-Prolog packages and avoids garnage collection by using @ref slotInterface. Last, a new C++ based interface is
being designed to work with the swig (www.swig.orgv) interface compiler.
+ The @ref c-interface exports the YAP engine.
+ The @ref swi-c-interface emulates Jan Wielemaker's SWI foreign language interface.
+ The @ref yap-cplus-interface is desiged to interface with the SWIG package by using Object-Oriented concepts
+ The @ref LoadInterface handles the setup of foreign files

0
docs/install.md
View File

58
docs/library.md Normal file
View File

@@ -0,0 +1,58 @@
The YAP Library (#library)
==============
Library files reside in 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.
- @ref apply
- @ref apply_macros
- @ref arg
- @ref Association_Lists
- @ref avl
- @ref bhash
- @ref block_diagram
- @ref c_alarms
- @ref charsio
- @ref clauses
- @ref cleanup
- @ref dbqueues
- @ref dbusage
- @ref dgraphs
- @ref exo_interval
- @ref flags
- @ref gensym
- @ref yap_hacks
- @ref heaps
- @ref lam_mpi
- @ref line_utils
- @ref swi_listing
- @ref lists
- @ref mapargs
- @ref maplist
- @ref matlab
- @ref matrix
- @ref nb
- @ref Ordered_Sets
- @ref parameters
- @ref queues
- @ref random
- @ref Pseudo_Random
- @ref rbtrees
- @ref regexp
- @ref rltrees
- @ref Splay_Trees
- @ref operating_system_support,
- @ref Terms
- @ref timeout
- @ref trees
- @ref tries
- @ref ugraphs
- @ref undgraphs
- @ref varnumbers
- @ref wdgraphs
- @ref wdgraphs
- @ref wdgraphs
- @ref wgraphs
- @ref wundgraphs
- @ref ypp

11
docs/load_files.md Normal file
View File

@@ -0,0 +1,11 @@
Loading and Oganising YAP Programs {#consult}
===================================
Next, we present the main predicates and directives available to load
files and to control the Prolog environment.
+ @ref YAPConsulting
+ @subpage YAPModules
+ @ref YAPSaving

28
docs/packages.md
View File

@@ -0,0 +1,28 @@
YAP packages files {#packages}
===================
+ @subpage real
+ @ref BDDs
+ @subpage ecode
+ @subpage myddas
+ @ref PFL/CLP(BN)
+ @ref ProbLog1
+ @ref Python
+ @subpage YAPRaptor
+ @ref YAP-LBFGS
+ @subpage yap-udi-indexers
Leuven packages ported from SWI-Prolog:
+ @subpage chr
+ @subpage clpqr

19
docs/run.md
View File

@@ -1,4 +1,4 @@
Running YAP
Running YAP {#run}
===========
We next describe how to invoke YAP in Unix systems.
@@ -24,7 +24,7 @@ specify <tt>M</tt> bytes.
allocate _Size_ KBytes for heap and auxiliary stacks
+ -t _Size_
allocate _Size_ KBytes for the trail stack
+ -L _Size_
+ -L _Size_
SWI-compatible option to allocate _Size_ K bytes for local and global stacks, the local stack
cannot be expanded. To avoid confusion with the load option, _Size_
must immediately follow the letter `L`.
@@ -62,34 +62,34 @@ through the unix/1 built-in predicate.
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
YAP state;
+
+
the necessary amount of memory could not be allocated;
+
+
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.
+
+
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
the environment variable YAPBINDIR.
+
+
YAP always tries to find saved states from the current directory
first. If it cannot it will use the environment variable YAPLIBDIR, if
defined, or search the default library directory.
+
+
YAP will try to find library files from the YAPSHAREDIR/library
directory.
@@ -188,4 +188,3 @@ they must be sent directly to the argv built-in. Hence, running
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
will write `test` on the standard output.

182
docs/swi.md
View File

@@ -0,0 +1,182 @@
Compatibility with other Prolog systems {#swi}
=======================================
YAP has been designed to be as compatible as possible with other
Prolog systems, originally with C-Prolog\cite x and SICStus
Prolog~\cite x . More recent work on YAP has striven at making YAP
compatible with the ISO-Prolog standard\cite x , and with Jan
Wielemaker's SWI-Prolog\cite x .
SWI-Prolog and YAP have collaborated at improved compatibility \cite x . This
resulted in Prolog extensions such as the `dialect` feature. YAP
currently supports most of the SWI-Prolog foreign interface. The following SWI
libraries have been adapted to YAP:
+ @ref aggregate
+ @ref base64
+ @ref broadcast
+ @ref ctypes
+ @ref date
+ @ref prolog_debug
+ @ref prolog_edit
+ @ref error
+ @ref nb_set
+ @ref prolog_operator
+ @ref swi_option
+ @ref pairs
+ @ref pio
+ @ref predicate_options,
+ @ref predopts
+ @ref prolog_clause
+ @ref prolog_colour
+ @ref prolog_source
+ @ref prolog_xref
+ @ref pure_input
+ @ref quasi_quotations
+ @ref read_util
+ @ref record
+ @ref settings
+ @ref shlib
+ @ref thread_pool
+ @ref url
+ @ref utf8
+ @ref win_menu
+ @ref www_browser
Note that in general SWI code may be from an earlier version than the
one available with SWI-Prolog. SWI-Prolog are obviously not
responsible for any incompatibilities and/or bugs in the YAP port.
Please do refer to the SWI-Prolog home page:
<http://www.swi-prolog.org>
for more information on SWI-Prolog and the SWI packages.
Compatibility with the C-Prolog interpreter {#ChYProlog}
-------------------------------------------
YAP was designed so that most C-Prolog programs should run under YAP
without changes.
The most important difference between YAP and C-Prolog is that, being
YAP a compiler, some changes should be made if predicates such as
assert/1, clause/1 and retract/1 are used. First
predicates which will change during execution should be declared as
`dynamic` by using commands like:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:- dynamic f/n.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
where `f` is the predicate name and n is the arity of the
predicate. Note that several such predicates can be declared in a
single command:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:- dynamic f/2, ..., g/1.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Primitive predicates such as `retract` apply only to dynamic
predicates. Finally note that not all the C-Prolog primitive predicates
are implemented in YAP. They can easily be detected using the
`unknown` system predicate provided by YAP.
Last, by default YAP enables character escapes in strings. You can
disable the special interpretation for the escape character by using:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:- yap_flag(character_escapes,off).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
or by using:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:- yap_flag(language,cprolog).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Compatibility with the Quintus and SICStus Prolog systems
---------------------------------------------------------
The Quintus Prolog system was the first Prolog compiler to use Warren's
Abstract Machine. This system was very influential in the Prolog
community. Quintus Prolog implemented compilation into an abstract
machine code, which was then emulated. Quintus Prolog also included
several new built-ins, an extensive library, and in later releases a
garbage collector. The SICStus Prolog system, developed at SICS (Swedish
Institute of Computer Science), is an emulator based Prolog system
largely compatible with Quintus Prolog. SICStus Prolog has evolved
through several versions. The current version includes several
extensions, such as an object implementation, co-routining, and
constraints.
Both YAP and SICStus Prolog obey the Edinburgh Syntax and are based on
the WAM. Even so, there are major important differences:
+ Differently from SICStus Prolog, both consulted and dynamic code in YAP
are compiled, not interpreted. All code in YAP is compiled.
+ The following SICStus Prolog v3 built-ins are not (currently)
implemented in YAP (note that this is only a partial list):
stream_interrupt/3, reinitialize/0, help/0, help/1,
trimcore/0, and require/1.
+ The consult/1 predicate in YAP follows C-Prolog
semantics. That is, it adds clauses to the data base, even for
preexisting procedures. This is different from consult/1 in
SICStus Prolog or SWI-Prolog.
+ This list is incomplete.
Compatibility with the ISO Prolog standard
------------------------------------------
The Prolog standard was developed by ISO/IEC JTC1/SC22/WG17, the
international standardization working group for the programming language
Prolog. The book "Prolog: The Standard" by Deransart, Ed-Dbali and
Cervoni gives a complete description of this standard. Development in
YAP from YAP4.1.6 onwards have striven at making YAP
compatible with ISO Prolog. As such:
+ YAP now supports all of the built-ins required by the
ISO-standard, and,
+ Error-handling is as required by the standard.
YAP by default is not fully ISO standard compliant. You can set the
language flag to `iso` to obtain better
compatibility. Setting this flag changes the following:
+ By default, YAP implements the
atom_chars/2 (see Testing Terms), and
number_chars/2, (see Testing Terms),
built-ins as per the original Quintus Prolog definition, and
not as per the ISO definition.
Calling `set_prolog_flag(to_chars_mode,iso)` will switch
YAP to use the ISO definition for
atom_chars/2 and number_chars/2.
+ By default, YAP allows executable goals in directives. In ISO mode
most directives can only be called from top level (the exceptions are
set_prolog_flag/2 and op/3).
+ Error checking for meta-calls under ISO Prolog mode is stricter
than by default.
+ The strict_iso flag automatically enables the ISO Prolog
standard. This feature should disable all features not present in the
standard.
The following incompatibilities between YAP and the ISO standard are
known to still exist (please check Ulrich Neumerkel's page for more details):
<ul>
<li>Currently, YAP does not handle overflow errors in integer
operations, and handles floating-point errors only in some
architectures. Otherwise, YAP follows IEEE arithmetic.
Please inform the authors on other incompatibilities that may still
exist.

33
docs/syntax.md
View File

@@ -1,6 +1,5 @@
@file syntax.md
YAP Syntax (#YAPSyntax)
============
@defgroup YAPSyntax YAP Syntax
@ingroup mainpage
@@ -198,11 +197,11 @@ YAP supports four different textual elements:
data-base. They are stored either in ISO-LATIN-1 (first 256 code points), or as UTF-32.
+ Strings are atomic representations of text. The back-quote character is used to identify these objects in the program. Strings exist as stack objects, in the same way as other Prolog terms. As Prolog unification cannot be used to manipulate strings, YAP includes built-ins such as string_arg/3, sub_string/5, or string_concat to manipulate them efficiently. Strings are stored as opaque objects containing a
+ Lists of codes represent text as a list of numbers, where each number is a character code. A string of _N_ bytes requires _N_ pairs, that is _2N_ cells, leading to a total of 16 bytes per character on 64 byte machines. Thus, they are a very expensive, but very flexible representation, as one can use unification to construct and access string elements.
+ Lists of atoms represent text as a list of atoms, where each number has a single character code. A string of _N_ bytes also requires _2N_ pairs. They have similar properties to lists of codes.
The flags `double_quotes` and `backquoted_string` change the interpretation of text strings, they can take the
values `atom`, `string`, `codes`, and `chars`.
@@ -213,7 +212,7 @@ Examples:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The first string is an empty string, the last string shows the use of
double-quoting.
double-quoting.
Escape sequences can be used to include the non-printable characters
`a` (alert), `b` (backspace), `r` (carriage return),
@@ -346,7 +345,7 @@ atoms. If the text fits in ISO Latin-1, it is represented as an array
of 8-bit characters. Otherwise the text is represented as an array of
wide chars, which may take 16 or 32 bits. This representational issue
is completely transparent to the Prolog user. Users of the foreign
language interface sometimes need to be aware of these issues though. Notice that this will likely
language interface sometimes need to be aware of these issues though. Notice that this will likely
change in the future, we probably will use an UTF-8 based representation.
Character coding comes into view when characters of strings need to be
@@ -359,7 +358,7 @@ as well as I/O through network sockets.
@ingroup WideChars
The UCS standard describes all possible characters (or code points, as they include
ideograms, ligatures, and other symbols). The current version, Unicode 8.0, allows
ideograms, ligatures, and other symbols). The current version, Unicode 8.0, allows
code points up to 0x10FFFF, and thus allows for 1,114,112 code points. See [Unicode Charts](http://unicode.org/charts/) for the supported languages.
Notice that most symbols are rarely used. Encodings represent the Unicode characters in a way
@@ -367,23 +366,23 @@ that is more suited for communication. The most popular encoding, especially in
UTF-8. UTF-8 is compact and as it uses bytes, does not have different endianesses.
Bytes 0...127 represent simply the corresponding US-ASCII
character, while bytes 128...255 are used for multi-byte
encoding of characters placed higher in the UCS space.
encoding of characters placed higher in the UCS space.
Especially on
MS-Windows and Java the 16-bit Unicode standard, represented by pairs of bytes is
also popular. Originally, Microsoft supported a UCS-2 with 16 bits that
also popular. Originally, Microsoft supported a UCS-2 with 16 bits that
could represent only up to 64k characters. This was later extended to support the full
Unicode, we will call the latter version UTF-16. The extension uses a hole in the first 64K code points. Characters above 0xFFFF are divided into two 2-byte words, each one in that hole. There are two versions of UTF-16: big and low
endian. By default, UTF-16 is big endian, in practice most often it is used on Intel
hardware that is naturally little endian.
UTF-32, often called UCS-4, provides a natural interface where a code point is coded as
UTF-32, often called UCS-4, provides a natural interface where a code point is coded as
four octets. Unfortunately, it is also more expensive, so it is not as widely used.
Last, other encodings are also commonly used. One such legacy encoding is ISO-LATIN-1, that
supported latin based languages in western europe. YAP currently uses either ISO-LATIN-1 or UTF-32
internally.
Prolog supports the default encoding used by the Operating System,
Namely, YAP checks the variables LANG, LC_ALL and LC_TYPE. Say, if at boot YAP detects that the
environment variable `LANG` ends in "UTF-8", this encoding is
@@ -419,7 +418,7 @@ but generates errors and warnings on encountering values above
8-bit encoding supporting many western languages. This causes
the stream to be read and written fully untranslated.
+ `text`
+ `text`
C-library default locale encoding for text files. Files are read and
written using the C-library functions `mbrtowc()` and
`wcrtomb()`. This may be the same as one of the other locales,
@@ -484,7 +483,7 @@ writing, writing a BOM can be requested using the option
`bom(true)` with `open/4`. YAP will parse an UTF-8 file for a BOM only if explicitly required to do so. Do notice that YAP will write a BOM by default on UTF-16 (including UCS-2) and
UTF-32; otherwise the default is not to write a BOM. BOMs are not avaliable for ASCII and
ISO-LATIN-1.
= @addgroup Operators Summary of YAP Predefined Operators
@ingroup YapSyntax

601
docs/yap.md
View File

@@ -1,31 +1,31 @@
YAP 6-3.4 Manual {#mainpage}
====================
This file documents the YAP Prolog System version 6.3.4, a high-performance Prolog compiler developed at LIACC, Universidade do Porto. YAP is based on David H. D. Warren's WAM (Warren Abstract Machine), with several optimizations for better performance. YAP follows the Edinburgh tradition, and is largely compatible with DEC-10 Prolog, Quintus Prolog, and especially with C-Prolog.
This file documents the YAP Prolog System version 6.3.4, a high-performance Prolog compiler developed at LIACC, Universidade do Porto. YAP is based on David H. D. Warren's WAM (Warren Abstract Machine), with several optimizations for better performance. YAP follows the Edinburgh tradition, and is largely compatible with DEC-10 Prolog, Quintus Prolog, and originally with C-Prolog.
+ @ref download
The manual is organised as follows:
+ @ref install
+ @ref run
+ @subpage download
+ @ref YAPSyntax
+ @subpage install
+ @ref consult
+ @subpage run
+ @ref builtins
+ @subpage builtins
+ @ref extensions
+ @subpage extensions
+ @ref library
+ @subpage library
+ @ref packages
+ @subpage swi
+ @ref swi
+ @subpage packages
+ @ref YAPProgramming
+ @subpage YAPProgramming
+ @subpage Fli
+ @ref fli
@@ -51,578 +51,3 @@ originally from the SWI-Prolog manual, with the gracious authorization
from
Jan Wielemaker. We would also like to gratefully
acknowledge the contributions from Ashwin Srinivasian.
Loading and Organising YAP Programs {#consult}
===================================
@ingroup main
Next, we present the main predicates and directives available to load
files and to control the Prolog environment.
+ @ref YAPConsulting
+ @ref YAPModules
+@ref YAPSaving
This chapter describes the predicates controlling the execution of
Prolog programs.
In the description of the arguments of functors the following notation
will be used:
+ a preceding plus sign will denote an argument as an "input
argument" - 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.
Running YAP {#run}
===========
We next describe how to invoke YAP in Unix systems.
Running YAP Interactively
-------------------------
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
Unix with the following command:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
yap [-s n] [-h n] [-a n] [-c IP_HOST port ] [filename]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
All the arguments and flags are optional and have the following meaning:
+ -?
print a short error message.
+ -s _Size_
allocate _Size_ KBytes for local and global stacks. The user may
specify <tt>M</tt> bytes.
+ -h _Size_
allocate _Size_ KBytes for heap and auxiliary stacks
+ -t _Size_
allocate _Size_ KBytes for the trail stack
+ -L _Size_
SWI-compatible option to allocate _Size_ K bytes for local and global stacks, the local stack
cannot be expanded. To avoid confusion with the load option, _Size_
must immediately follow the letter `L`.
+ -G _Size_
SWI-compatible option to allocate _Size_ K bytes for local and global stacks; the global
stack cannot be expanded
+ -T _Size_
SWI-compatible option to allocate _Size_ K bytes for the trail stack; the trail cannot be expanded.
+ -l _YAP_FILE_
compile the Prolog file _YAP_FILE_ before entering the top-level.
+ -L _YAP_FILE_
compile the Prolog file _YAP_FILE_ and then halt. This option is
useful for implementing scripts.
+ -g _Goal_
run the goal _Goal_ before top-level. The goal is converted from
an atom to a Prolog term.
+ -z _Goal_
run the goal _Goal_ as top-level. The goal is converted from
an atom to a Prolog term.
+ -b _BOOT_FILE_
boot code is in Prolog file _BOOT_FILE_. The filename must define
the predicate `'$live'/0`.
+ -c <tt>IP_HOST</tt> <tt>port</tt>
connect standard streams to host <tt>IP_HOST</tt> at port <tt>port</tt>
+ filename
restore state saved in the given file
+ -f
do not consult initial files
+ -q
do not print informational messages
+ --
separator for arguments to Prolog code. These arguments are visible
through the unix/1 built-in predicate.
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
YAP state;
+
the necessary amount of memory could not be allocated;
+
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.
+
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
the environment variable YAPBINDIR.
+
YAP always tries to find saved states from the current directory
first. If it cannot it will use the environment variable YAPLIBDIR, if
defined, or search the default library directory.
+
YAP will try to find library files from the YAPSHAREDIR/library
directory.
Prolog Scripts
--------------
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
that the shell comments are very important):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#!/usr/local/bin/yap -L --
#
# Hello World script file using YAP
#
# put a dot because of syntax errors .
:- write('Hello World'), nl.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The `#!` characters specify that the script should call the binary
file YAP. Notice that many systems will require the complete path to the
YAP binary. The `-L` flag indicates that YAP should consult the
current file when booting and then halt. The remaining arguments are
then passed to YAP. Note that YAP will skip the first lines if they
start with `#` (the comment sign for Unix's shell). YAP will
consult the file and execute any commands.
A slightly more sophisticated example is:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#!/usr/bin/yap -L --
#
# Hello World script file using YAP
# .
:- initialization(main).
main :- write('Hello World'), nl.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The `initialization` directive tells YAP to execute the goal main
after consulting the file. Source code is thus compiled and `main`
executed at the end. The `.` is useful while debugging the script
as a Prolog program: it guarantees that the syntax error will not
propagate to the Prolog code.
Notice that the `--` is required so that the shell passes the extra
arguments to YAP. As an example, consider the following script
`dump_args`:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#!/usr/bin/yap -L --
#.
main( [] ).
main( [H|T] ) :-
write( H ), nl,
main( T ).
:- unix( argv(AllArgs) ), main( AllArgs ).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you this run this script with the arguments:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./dump_args -s 10000
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
the script will start an YAP process with stack size `10MB`, and
the list of arguments to the process will be empty.
Often one wants to run the script as any other program, and for this it
is convenient to ignore arguments to YAP. This is possible by using
`L --` as in the next version of `dump_args`:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#!/usr/bin/yap -L --
main( [] ).
main( [H|T] ) :-
write( H ), nl,
main( T ).
:- unix( argv(AllArgs) ), main( AllArgs ).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The `--` indicates the next arguments are not for YAP. Instead,
they must be sent directly to the argv built-in. Hence, running
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./dump_args test
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
will write `test` on the standard output.
YAP Built-ins {#builtins}
=============
+ @ref YAPControl
+ @ref arithmetic
+ @ref YAPChars
+ @ref YAP_Terms
+ @ref InputOutput
+ @ref AbsoluteFileName
+ @ref YAPOS
+ @ref Internal_Database
+ @ref Sets
Extensions to core Prolog. {#extensions}
==========================
YAP includes a number of extensions over the original Prolog
language. Next, we discuss how to use the most important ones.
+ @ref Rational_Trees
+ @ref AttributedVariables
+ @ref DepthLimited
+ @ref Tabling
+ @ref Threads
+ @ref Profiling
+ @ref YAPArrays
+ @ref Parallelism
The YAP Library {#library}
===============
@defgroup library YAP library files
@{
Library files reside in 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.
- @ref apply
- @ref apply_macros
- @ref arg
- @ref Association_Lists
- @ref avl
- @ref bhash
- @ref block_diagram
- @ref c_alarms
- @ref charsio
- @ref clauses
- @ref cleanup
- @ref dbqueues
- @ref dbusage
- @ref dgraphs
- @ref exo_interval
- @ref flags
- @ref gensym
- @ref yap_hacks
- @ref heaps
- @ref lam_mpi
- @ref line_utils
- @ref swi_listing
- @ref lists
- @ref mapargs
- @ref maplist
- @ref matlab
- @ref matrix
- @ref nb
- @ref Ordered_Sets
- @ref parameters
- @ref queues
- @ref random
- @ref Pseudo_Random
- @ref rbtrees
- @ref regexp
- @ref rltrees
- @ref Splay_Trees
- @ref operating_system_support,
- @ref Terms
- @ref timeout
- @ref trees
- @ref tries
- @ref ugraphs
- @ref undgraphs
- @ref varnumbers
- @ref wdgraphs
- @ref wdgraphs
- @ref wdgraphs
- @ref wgraphs
- @ref wundgraphs
- @ref ypp
@}
The YAP Packages {#packages}
================
@defgroup packages YAP packages files
@{
+ @ref real
+ @ref BDDs
+ @ref Gecode
+ @ref MYDDAS
+ @ref PFL
+ @ref ProbLog1
+ @ref python
+ @ref YAPRaptor
+ @ref YAP-LBFGS
+ @subpage yap-udi-indexers
Leuven packages ported from SWI-Prolog:
+ @subpage chr
+ @subpage clpqr
@}
Compatibility {#swi}
=============
@defgroup swi Compatibility
@{
YAP has been designed to be as compatible as possible with other
Prolog systems, originally with C-Prolog\cite x and SICStus
Prolog~\cite x . More recent work on YAP has striven at making YAP
compatible with the ISO-Prolog standard\cite x , and with Jan
Wielemaker's SWI-Prolog\cite x .
SWI-Prolog and YAP have collaborated at improved compatibility \cite x . This
resulted in Prolog extensions such as the `dialect` feature. YAP
currently supports most of the SWI-Prolog foreign interface. The following SWI
libraries have worked on YAP:
+ @ref aggregate
+ @ref base64
+ @ref broadcast
+ @ref ctypes
+ @ref date
+ @ref prolog_debug
+ @ref prolog_edit
+ @ref error
+ @ref nb_set
+ @ref prolog_operator
+ @ref swi_option
+ @ref pairs
+ @ref pio
+ @ref predicate_options,
+ @ref predopts
+ @ref prolog_clause
+ @ref prolog_colour
+ @ref prolog_source
+ @ref prolog_xref
+ @ref pure_input
+ @ref quasi_quotations
+ @ref read_util
+ @ref record
+ @ref settings
+ @ref shlib
+ @ref thread_pool
+ @ref url
+ @ref utf8
+ @ref win_menu
+ @ref www_browser
Note that in general SWI code may be from an earlier version than the
one available with SWI-Prolog. SWI-Prolog are obviously not
responsible for any incompatibilities and/or bugs in the YAP port.
Please do refer to the SWI-Prolog home page:
<http://www.swi-prolog.org>
for more information on SWI-Prolog and the SWI packages.
Compatibility with the C-Prolog interpreter {#ChYProlog}
-------------------------------------------
YAP was designed so that most C-Prolog programs should run under YAP
without changes.
The most important difference between YAP and C-Prolog is that, being
YAP a compiler, some changes should be made if predicates such as
assert/1, clause/1 and retract/1 are used. First
predicates which will change during execution should be declared as
`dynamic` by using commands like:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:- dynamic f/n.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
where `f` is the predicate name and n is the arity of the
predicate. Note that several such predicates can be declared in a
single command:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:- dynamic f/2, ..., g/1.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Primitive predicates such as `retract` apply only to dynamic
predicates. Finally note that not all the C-Prolog primitive predicates
are implemented in YAP. They can easily be detected using the
`unknown` system predicate provided by YAP.
Last, by default YAP enables character escapes in strings. You can
disable the special interpretation for the escape character by using:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:- yap_flag(character_escapes,off).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
or by using:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
:- yap_flag(language,cprolog).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Compatibility with the Quintus and SICStus Prolog systems
---------------------------------------------------------
The Quintus Prolog system was the first Prolog compiler to use Warren's
Abstract Machine. This system was very influential in the Prolog
community. Quintus Prolog implemented compilation into an abstract
machine code, which was then emulated. Quintus Prolog also included
several new built-ins, an extensive library, and in later releases a
garbage collector. The SICStus Prolog system, developed at SICS (Swedish
Institute of Computer Science), is an emulator based Prolog system
largely compatible with Quintus Prolog. SICStus Prolog has evolved
through several versions. The current version includes several
extensions, such as an object implementation, co-routining, and
constraints.
Both YAP and SICStus Prolog obey the Edinburgh Syntax and are based on
the WAM. Even so, there are major important differences:
+ Differently from SICStus Prolog, both consulted and dynamic code in YAP
are compiled, not interpreted. All code in YAP is compiled.
+ The following SICStus Prolog v3 built-ins are not (currently)
implemented in YAP (note that this is only a partial list):
stream_interrupt/3, reinitialize/0, help/0, help/1,
trimcore/0, and require/1.
+ The consult/1 predicate in YAP follows C-Prolog
semantics. That is, it adds clauses to the data base, even for
preexisting procedures. This is different from consult/1 in
SICStus Prolog or SWI-Prolog.
+ This list is incomplete.
Compatibility with the ISO Prolog standard
------------------------------------------
The Prolog standard was developed by ISO/IEC JTC1/SC22/WG17, the
international standardization working group for the programming language
Prolog. The book "Prolog: The Standard" by Deransart, Ed-Dbali and
Cervoni gives a complete description of this standard. Development in
YAP from YAP4.1.6 onwards have striven at making YAP
compatible with ISO Prolog. As such:
+ YAP now supports all of the built-ins required by the
ISO-standard, and,
+ Error-handling is as required by the standard.
YAP by default is not fully ISO standard compliant. You can set the
language flag to `iso` to obtain better
compatibility. Setting this flag changes the following:
+ By default, YAP implements the
atom_chars/2 (see Testing Terms), and
number_chars/2, (see Testing Terms),
built-ins as per the original Quintus Prolog definition, and
not as per the ISO definition.
Calling `set_prolog_flag(to_chars_mode,iso)` will switch
YAP to use the ISO definition for
atom_chars/2 and number_chars/2.
+ By default, YAP allows executable goals in directives. In ISO mode
most directives can only be called from top level (the exceptions are
set_prolog_flag/2 and op/3).
+ Error checking for meta-calls under ISO Prolog mode is stricter
than by default.
+ The strict_iso flag automatically enables the ISO Prolog
standard. This feature should disable all features not present in the
standard.
The following incompatibilities between YAP and the ISO standard are
known to still exist (please check Ulrich Neumerkel's page for more details):
<ul>
<li>Currently, YAP does not handle overflow errors in integer
operations, and handles floating-point errors only in some
architectures. Otherwise, YAP follows IEEE arithmetic.
Please inform the authors on other incompatibilities that may still
exist.
@}
Foreign Language interface for YAP {#fli}
==================================
@defgroup fli Foreigd Code Interfacing
@{
YAP provides the user with three facilities for writing
predicates in a language other than Prolog. Under Unix systems,
most language implementations were linkable to `C`, and the first interface exported the YAP machinery to the C language. YAP also implements most of the SWI-Prolog foreign language interface.
This gives portability with a number of SWI-Prolog packages and avoids garnage collection by using @ref slotInterface. Last, a new C++ based interface is
being designed to work with the swig (www.swig.orgv) interface compiler.
+ The @ref c-interface exports the YAP engine.
+ The @ref swi-c-interface emulates Jan Wielemaker's SWI foreign language interface.
+ The @ref yap-cplus-interface is desiged to interface with the SWIG package by using Object-Oriented concepts
+ The @ref LoadInterface handles the setup of foreign files
@}