This commit is contained in:
Vitor Santos Costa 2017-05-02 07:42:21 +01:00
parent a6e6642eb2
commit 6e7846e210
27 changed files with 198 additions and 689 deletions

View File

@ -29,10 +29,11 @@ static char SccsId[] = "%W% %G%";
#endif
/**
@file attvar.c
@defgroup AttributeVariables_Builtins Implementation of Attribute Declarations
@{
@adefgroup AttributedVariables_Builtins Low-level support for Attributed Variables
@brief Implementation of Attribute Declarations
@ingroup attributes
@{
*/
#ifdef COROUTINING

View File

@ -3,6 +3,7 @@
# Sets the version of CMake required to build the native
# library. You should either keep the default value or pass a
# value of 3.4.0 or lower.
include(CMakeToolsHelpers OPTIONAL)
project( YAP )
@ -12,7 +13,6 @@ if (ANDROID)
else ()
cmake_minimum_required(VERSION 2.8)
include(CMakeToolsHelpers OPTIONAL)
endif()
set(

View File

@ -18,16 +18,18 @@
/** @file YapGFlagInfo.h
@addtogroup YAPFlags
*/
@ingroup builtins
@{
/** @pred yap_flag( ?Param, ?Value)
@pred yap_flag( ?Param, ?Value)
Set or read system properties for _Param_:
@enum YapGFlag Prolog
@enum YapGFlag Prolog
@Brief global flag:
@enum GlobalFlags Global Flags Dupported ny YAP *
*/
YAP_FLAG(ADDRESS_BITS_FLAG, "address_bits", false, nat, BITNESS, NULL), /**< `address_bits`
@ -553,3 +555,4 @@ integers that are writable character codes using the list notation. It
is `on` if enables or `off` if disabled. The default value for
this flag is `off`.
*/
//! @}

View File

@ -50,8 +50,11 @@ if (WITH_DOCS)
COMMENT "Generating API documentation with Doxygen"
VERBATIM)
if (EXISTS ${CMAKE_CURRENT_BINARY_DIR}/html)
install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/html DESTINATION ${docdir})
install(FILES ${CODES} DESTINATION ${docdir})
endif()
endif()

View File

@ -378,7 +378,7 @@ SUBGROUPING = YES
# SEPARATE_MEMBER_PAGES.
# The default value is: NO.
INLINE_GROUPED_CLASSES = NO
INLINE_GROUPED_CLASSES = YES
# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and unions
# with only public data fields or simple typedef fields will be shown inline in
@ -1116,9 +1116,7 @@ HTML_FILE_EXTENSION = .html
# of the possible markers and block names see the documentation.
# This tag requires that the tag GENERATE_HTML is set to YES.
HTML_HEADER =
#@CMAKE_SOURCE_DIR@/docs/web/bootstrap/header.html
HTML_HEADER = @CMAKE_SOURCE_DIR@/docs/custom/header.html
# The HTML_FOOTER tag can be used to specify a user-defined HTML footer for each
# generated HTML page. If the tag is left blank doxygen will generate a standard
@ -1128,9 +1126,7 @@ HTML_HEADER =
# that doxygen normally uses.
# This tag requires that the tag GENERATE_HTML is set to YES.
HTML_FOOTER =
#@CMAKE_SOURCE_DIR@/docs/web/bootstrap/footer.html
HTML_FOOTER = @CMAKE_SOURCE_DIR@/docs/custom/footer.html
# The HTML_STYLESHEET tag can be used to specify a user-defined cascading style
# sheet that is used by each HTML page. It can be used to fine-tune the look of
@ -1157,10 +1153,9 @@ HTML_STYLESHEET =
# list). For an example see the documentation.
# This tag requires that the tag GENERATE_HTML is set to YES.
HTML_EXTRA_STYLESHEET = @CMAKE_SOURCE_DIR@/docs/solarized-light.css
HTML_EXTRA_STYLESHEET = @CMAKE_SOURCE_DIR@/docs/custom/customdoxygen.css
# @CMAKE_SOURCE_DIR@/docs/solarized-light.css
# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or
# other source files which should be copied to the HTML output directory. Note
# that these files will be copied to the base HTML output directory. Use the
@ -1169,9 +1164,7 @@ HTML_EXTRA_STYLESHEET = @CMAKE_SOURCE_DIR@/docs/solarized-light.css
# files will be copied as-is; there are no commands or markers available.
# This tag requires that the tag GENERATE_HTML is set to YES.
HTML_EXTRA_FILES =
#@CMAKE_SOURCE_DIR@/docs/web/bootstrap/doxy-boot.js
HTML_EXTRA_FILES = @CMAKE_SOURCE_DIR@/docs/custom/doxy-boot.js
# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. Doxygen
# will adjust the colors in the style sheet and background images according to
@ -1573,7 +1566,7 @@ SEARCHENGINE = YES
# The default value is: NO.
# This tag requires that the tag SEARCHENGINE is set to YES.
SERVER_BASED_SEARCH = NO
SERVER_BASED_SEARCH = YES
# When EXTERNAL_SEARCH tag is enabled doxygen will no longer generate the PHP
# script for searching. Instead the search results are written to an XML file
@ -1589,7 +1582,7 @@ SERVER_BASED_SEARCH = NO
# The default value is: NO.
# This tag requires that the tag SEARCHENGINE is set to YES.
EXTERNAL_SEARCH = NO
EXTERNAL_SEARCH = YAP
# The SEARCHENGINE_URL should point to a search engine hosted by a web server
# which will return the search results when EXTERNAL_SEARCH is enabled.
@ -1616,7 +1609,7 @@ SEARCHDATA_FILE = searchdata.xml
# projects and redirect the results back to the right project.
# This tag requires that the tag SEARCHENGINE is set to YES.
EXTERNAL_SEARCH_ID =
EXTERNAL_SEARCH_ID = YAP
# The EXTRA_SEARCH_MAPPINGS tag can be used to enable searching through doxygen
# projects other than the one defined by this configuration file, but that are

View File

@ -1,392 +0,0 @@
Attributed Variables and Co-Routining {#attributes}
=======================================
@ingroup extensions
YAP supports attributed variables, originally developed at OFAI by
Christian Holzbaur. Attributes are a means of declaring that an
arbitrary term is a property for a variable. These properties can be
updated during forward execution. Moreover, the unification algorithm is
aware of attributed variables and will call user defined handlers when
trying to unify these variables.
Attributed variables provide an elegant abstraction over which one can
extend Prolog systems. Their main application so far has been in
implementing constraint handlers, such as Holzbaur's CLPQR, Fruewirth
and Holzbaur's CHR, and CLP(BN).
Different Prolog systems implement attributed variables in different
ways. Originally, YAP used the interface designed by SICStus
Prolog. This interface is still
available through the <tt>atts</tt> library, and is used by CLPBN.
From YAP-6.0.3 onwards we recommend using the hProlog, SWI style
interface. We believe that this design is easier to understand and
work with. Most packages included in YAP that use attributed
variables, such as CHR, CLP(FD), and CLP(QR), rely on the SWI-Prolog
interface.
+ @ref SICS_attributes
+ @ref New_Style_Attribute_Declarations
+ @ref CohYroutining
+ @ref AttributeVariables_Builtins
@section SICS_attributes SICStus Style attribute declarations.
The YAP library `atts` implements attribute variables in the style of
SICStus Prolog. Attributed variables work as follows:
+ Each attribute must be declared beforehand. Attributes are described
as a functor with name and arity and are local to a module. Each
Prolog module declares its own sets of attributes. Different modules
may have attributes with the same name and arity.
+ The built-in put_atts/2 adds or deletes attributes to a
variable. The variable may be unbound or may be an attributed
variable. In the latter case, YAP discards previous values for the
attributes.
+ The built-in get_atts/2 can be used to check the values of
an attribute associated with a variable.
+ The unification algorithm calls the user-defined predicate
verify_attributes/3 before trying to bind an attributed
variable. Unification will resume after this call.
+ The user-defined predicate
<tt>attribute_goal/2</tt> converts from an attribute to a goal.
+ The user-defined predicate
<tt>project_attributes/2</tt> is used from a set of variables into a set of
constraints or goals. One application of <tt>project_attributes/2</tt> is in
the top-level, where it is used to output the set of
floundered constraints at the end of a query.
Attributes are compound terms associated with a variable. Each attribute
has a <em>name</em> which is <em>private</em> to the module in which the
attribute was defined. Variables may have at most one attribute with a
name. Attribute names are defined through the following declaration:
~~~~~
:- attribute AttributeSpec, ..., AttributeSpec.
~~~~~
where each _AttributeSpec_ has the form ( _Name_/ _Arity_).
One single such declaration is allowed per module _Module_.
Although the YAP module system is predicate based, attributes are local
to modules. This is implemented by rewriting all calls to the
built-ins that manipulate attributes so that attribute names are
preprocessed depending on the module. The `user:goal_expansion/3`
mechanism is used for this purpose.
The attribute manipulation predicates always work as follows:
+ The first argument is the unbound variable associated with
attributes,
+ 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
operators. The prefix <tt>+</tt> may be dropped for convenience.
The following three procedures are available to the user. Notice that
these built-ins are rewritten by the system into internal built-ins, and
that the rewriting process <em>depends</em> on the module on which the
built-ins have been invoked.
The user-predicate predicate verify_attributes/3 is called when
attempting to unify an attributed variable which might have attributes
in some _Module_.
Attributes are usually presented as goals. The following routines are
used by built-in predicates such as call_residue/2 and by the
Prolog top-level to display attributes:
Constraint solvers must be able to project a set of constraints to a set
of variables. This is useful when displaying the solution to a goal, but
may also be used to manipulate computations. The user-defined
project_attributes/2 is responsible for implementing this
projection.
The following examples are taken from the SICStus Prolog
manual. The sketches the implementation of a simple finite domain
`solver`. Note that an industrial strength solver would have to
provide a wider range of functionality and that it quite likely would
utilize a more efficient representation for the domains proper. The
module exports a single predicate `domain( _-Var_, _?Domain_)` which
associates _Domain_ (a list of terms) with _Var_. A variable can be
queried for its domain by leaving _Domain_ unbound.
We do not present here a definition for project_attributes/2.
Projecting finite domain constraints happens to be difficult.
~~~~~
:- module(domain, [domain/2]).
:- use_module(library(atts)).
:- use_module(library(ordsets), [
ord_intersection/3,
ord_intersect/2,
list_to_ord_set/2
]).
:- attribute dom/1.
verify_attributes(Var, Other, Goals) :-
get_atts(Var, dom(Da)), !, % are we involved?
( var(Other) -> % must be attributed then
( get_atts(Other, dom(Db)) -> % has a domain?
ord_intersection(Da, Db, Dc),
Dc = [El|Els], % at least one element
( Els = [] -> % exactly one element
Goals = [Other=El] % implied binding
; Goals = [],
put_atts(Other, dom(Dc))% rescue intersection
)
; Goals = [],
put_atts(Other, dom(Da)) % rescue the domain
)
; Goals = [],
ord_intersect([Other], Da) % value in domain?
).
verify_attributes(_, _, []). % unification triggered
% because of attributes
% in other modules
attribute_goal(Var, domain(Var,Dom)) :- % interpretation as goal
get_atts(Var, dom(Dom)).
domain(X, Dom) :-
var(Dom), !,
get_atts(X, dom(Dom)).
domain(X, List) :-
list_to_ord_set(List, Set),
Set = [El|Els], % at least one element
( Els = [] -> % exactly one element
X = El % implied binding
; put_atts(Fresh, dom(Set)),
X = Fresh % may call
% verify_attributes/3
).
~~~~~
Note that the _implied binding_ `Other=El` was deferred until after
the completion of `verify_attribute/3`. Otherwise, there might be a
danger of recursively invoking `verify_attribute/3`, which might bind
`Var`, which is not allowed inside the scope of `verify_attribute/3`.
Deferring unifications into the third argument of `verify_attribute/3`
effectively serializes the calls to `verify_attribute/3`.
Assuming that the code resides in the file domain.yap, we
can use it via:
~~~~~
| ?- use_module(domain).
~~~~~
Let's test it:
~~~~~
| ?- domain(X,[5,6,7,1]), domain(Y,[3,4,5,6]), domain(Z,[1,6,7,8]).
domain(X,[1,5,6,7]),
domain(Y,[3,4,5,6]),
domain(Z,[1,6,7,8]) ?
yes
| ?- domain(X,[5,6,7,1]), domain(Y,[3,4,5,6]), domain(Z,[1,6,7,8]),
X=Y.
Y = X,
domain(X,[5,6]),
domain(Z,[1,6,7,8]) ?
yes
| ?- domain(X,[5,6,7,1]), domain(Y,[3,4,5,6]), domain(Z,[1,6,7,8]),
X=Y, Y=Z.
X = 6,
Y = 6,
Z = 6
~~~~~
To demonstrate the use of the _Goals_ argument of
verify_attributes/3, we give an implementation of
freeze/2. We have to name it `myfreeze/2` in order to
avoid a name clash with the built-in predicate of the same name.
~~~~~
:- module(myfreeze, [myfreeze/2]).
:- use_module(library(atts)).
:- attribute frozen/1.
verify_attributes(Var, Other, Goals) :-
get_atts(Var, frozen(Fa)), !, % are we involved?
( var(Other) -> % must be attributed then
( get_atts(Other, frozen(Fb)) % has a pending goal?
-> put_atts(Other, frozen((Fa,Fb))) % rescue conjunction
; put_atts(Other, frozen(Fa)) % rescue the pending goal
),
Goals = []
; Goals = [Fa]
).
verify_attributes(_, _, []).
attribute_goal(Var, Goal) :- % interpretation as goal
get_atts(Var, frozen(Goal)).
myfreeze(X, Goal) :- put_atts(Fresh, frozen(Goal)), Fresh = X. ~~~~~
Assuming that this code lives in file myfreeze.yap,
we would use it via:
~~~~~
| ?- use_module(myfreeze).
| ?- myfreeze(X,print(bound(x,X))), X=2.
bound(x,2) % side effect
X = 2 % bindings
~~~~~
The two solvers even work together:
~~~~~
| ?- myfreeze(X,print(bound(x,X))), domain(X,[1,2,3]),
domain(Y,[2,10]), X=Y.
bound(x,2) % side effect
X = 2, % bindings
Y = 2
~~~~~
The two example solvers interact via bindings to shared attributed
variables only. More complicated interactions are likely to be found
in more sophisticated solvers. The corresponding
verify_attributes/3 predicates would typically refer to the
attributes from other known solvers/modules via the module prefix in
Module:get_atts/2`.
@}
@{
@defgroup New_Style_Attribute_Declarations hProlog and SWI-Prolog style Attribute Declarations
The following documentation is taken from the SWI-Prolog manual.
Binding an attributed variable schedules a goal to be executed at the
first possible opportunity. In the current implementation the hooks are
executed immediately after a successful unification of the clause-head
or successful completion of a foreign language (built-in) predicate. Each
attribute is associated to a module and the hook attr_unify_hook/2 is
executed in this module. The example below realises a very simple and
incomplete finite domain reasoner.
~~~~~
:- module(domain,
[ domain/2 % Var, ?Domain %
]).
:- use_module(library(ordsets)).
domain(X, Dom) :-
var(Dom), !,
get_attr(X, domain, Dom).
domain(X, List) :-
list_to_ord_set(List, Domain),
v put_attr(Y, domain, Domain),
X = Y.
% An attributed variable with attribute value Domain has been %
% assigned the value Y %
attr_unify_hook(Domain, Y) :-
( get_attr(Y, domain, Dom2)
-> ord_intersection(Domain, Dom2, NewDomain),
( NewDomain == []
-> fail
; NewDomain = [Value]
-> Y = Value
; put_attr(Y, domain, NewDomain)
)
; var(Y)
-> put_attr( Y, domain, Domain )
; ord_memberchk(Y, Domain)
).
% Translate attributes from this module to residual goals %
attribute_goals(X) -->
{ get_attr(X, domain, List) },
[domain(X, List)].
~~~~~
Before explaining the code we give some example queries:
The predicate `domain/2` fetches (first clause) or assigns
(second clause) the variable a <em>domain</em>, a set of values it can
be unified with. In the second clause first associates the domain
with a fresh variable and then unifies X to this variable to deal
with the possibility that X already has a domain. The
predicate attr_unify_hook/2 is a hook called after a variable with
a domain is assigned a value. In the simple case where the variable
is bound to a concrete value we simply check whether this value is in
the domain. Otherwise we take the intersection of the domains and either
fail if the intersection is empty (first example), simply assign the
value if there is only one value in the intersection (second example) or
assign the intersection as the new domain of the variable (third
example). The nonterminal `attribute_goals/3` is used to translate
remaining attributes to user-readable goals that, when executed, reinstate
these attributes.
@}
@{
@defgroup CohYroutining Co-routining
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
sufficiently instantiated. This may result in a more "data-driven"
execution, or may be necessary to correctly implement extensions such
as negation by failure.
Initially, YAP used a separate mechanism for co-routining. Nowadays, YAP uses
attributed variables to implement co-routining.
Two declarations are supported:
+ block/1
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 the form `predname( _C1_,..., _CN_)`, where _N_ is 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
`?`, otherwise.
+ wait/1
The argument to `wait/1` is a predicate descriptor or a conjunction
of these predicates. These predicates will suspend until their first
argument is bound.
The following primitives can be used:
- freeze/2
- dif/2
- when/2
- frozen/2
@}
@}

View File

@ -1,19 +0,0 @@
Boolean Decision Making in YAP {#BDDs}
==============================
This is an experimental interface to BDD libraries. It is not as
sophisticated as simplecudd, but it should be fun to play around with bdds.
It currently works with cudd only, although it should be possible to
port to other libraries. It requires the ability to dynamically link
with cudd binaries. This works:
- in fedora with standard package
- in osx with hand-compiled and ports package
In ubuntu, you may want to install the fedora rpm, or just download the package from the original
and compile it.
+ @ref BDDsPL
+ @ref CUDD

View File

@ -1,15 +0,0 @@
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 Prolog also known as ISO-Prolog.
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" - 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.

View File

@ -1,14 +0,0 @@
Downloading YAP {#download}
==============
The latest development version of Yap-6 is yap-6.3.5 and can be
obtained from the repositories
+ [https://github.com/vscosta/yap-6.3]{github}
and an older version at:
+ [http://sourceforge.net/p/yap/yap-6.3]{sourceforge}
YAP-6.3.5 does not use git submodules. Please just use `git clone` to obtain the distribution.

View File

@ -1,24 +1,21 @@
Extensions to core Prolog. {#extensions}
Extensions to core Prolog. {#extensions}
========================
YAP includes a number of extensions over the original Prolog
language.
+ @ref Rational_Trees
+ @subpage attributes
+ @subpage attributes
+ @ref Rational_Trees
+ @ref DepthLimited
+ @ref DepthLimited
+ @ref Tabling
+ @ref Tabling
+ @ref Threads
+ @ref Profiling
+ @ref YAPArrays
+ @ref Parallelism
+ @ref Threads
+ @ref Profiling
+ @ref YAPArrays
+ @ref Parallelism

View File

@ -7,13 +7,13 @@ most language implementations were linkable to `C`, and the first interface expo
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 @subpage c-interface
+ The @subpage c-interface
+ The @ref swi-c-interface emulates Jan Wielemaker's SWI foreign language interface.
+ 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 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
+ The @ref LoadForeign handles the setup of foreign files
@ -125,8 +125,7 @@ init_my_predicates() was passed as the third argument to
load_foreign_files/3.
The rest of this appendix describes exhaustively how to interface C to YAP.
@section Manipulating_Terms Terms
### Terms {#Manipulating_Terms}
This section provides information about the primitives available to the C
programmer for manipulating Prolog terms.
@ -498,8 +497,7 @@ You can set _min_ to zero if you do not know how much room you need
but you do know you do not need a big chunk at a single go. Usually, the routine
would usually be called together with a long-jump to restart the
code. Slots can also be used if there is small state.
@section Unifying_Terms Unification
### Unification {#Unifying_Terms}
YAP provides a single routine to attempt the unification of two Prolog
terms. The routine may succeed or fail:
@ -512,8 +510,7 @@ terms. The routine may succeed or fail:
The routine attempts to unify the terms _a_ and
_b_ returning `TRUE` if the unification succeeds and `FALSE`
otherwise.
@section Manipulating_Strings Strings
### Strings {#Manipulating_Strings}
The YAP C-interface now includes an utility routine to copy a string
represented as a list of a character codes to a previously allocated buffer
@ -593,8 +590,7 @@ These C-interface functions are useful when converting Prolog lists to arrays:
</ul>
They return the number of integers scanned, up to a maximum of <tt>sz</tt>,
and <tt>-1</tt> on error.
@section Memory_Allocation Memory Allocation
### Memory Allocation {#Memory_Allocation}
The next routine can be used to ask space from the Prolog data-base:
@ -618,8 +614,7 @@ back to YAP by using:
The routine releases a buffer allocated from the code area. The system
may crash if `buf` is not a valid pointer to a buffer in the code
area.
@section Controlling_Streams Controlling YAP Streams from `C`
### Controlling YAP Streams from `C` {#Controlling_Streams}
The C-Interface also provides the C-application with a measure of
control over the YAP Input/Output system. The first routine allows one
@ -674,8 +669,7 @@ The available flags are `YAP_INPUT_STREAM`,
`YAP_BINARY_STREAM`, and `YAP_SEEKABLE_STREAM`. By default, the
stream is supposed to be at position 0. The argument _name_ gives
the name by which YAP should know the new stream.
@section Utility_Functions Utility Functions in `C`
### Utility Functions in `C` {#Utility_Functions}
The C-Interface provides the C-application with a a number of utility
functions that are useful.
@ -766,8 +760,7 @@ ignore_variables));
The first three arguments follow `term_has/4`. The last argument
indicates what to do if we find a variable: if `0` fail, otherwise
ignore the variable.
@section Calling_YAP_From_C From `C` back to Prolog
### From `C` back to Prolog {#Calling_YAP_From_C}
There are several ways to call Prolog code from C-code. By default, the
`YAP_RunGoal()` should be used for this task. It assumes the engine
@ -937,8 +930,7 @@ finding the first solution to the goal, but you can call
Notice that during execution, garbage collection or stack shifting may
have moved the terms
@section Module_Manipulation_in_C Module Manipulation in C
### Module Manipulation in C {#Module_Manipulation_in_C}
YAP allows one to create a new module from C-code. To create the new
code it is sufficient to call:
@ -964,8 +956,7 @@ possible by using:
</ul>
Notice that this function returns a term, and not an atom. You can
[YAP_AtomOfTerm](@ref YAP_AtomOfTerm) to extract the corresponding Prolog atom.
@section Miscellaneous_ChYFunctions Miscellaneous C Functions
### Miscellaneous C Functions {#Miscellaneous_ChYFunctions}
<ul>
<li>`void` YAP_Throw(`YAP_Term exception`)
@ -1026,8 +1017,7 @@ of such arguments.
</li>
</ul>
@section Writing_C Writing predicates in C
### Writing predicates in C {#Writing_C}
We will distinguish two kinds of predicates:
@ -1278,9 +1268,7 @@ init_n100(void)
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
in this case no code is executed at cut time.
@section YAP4_Notes Changes to the C-Interface in YAP4
### Changes to the C-Interface in YAP4 {#YAP4_Notes}
YAP4 includes several changes over the previous `load_foreign_files/3`
interface. These changes were required to support the new binary code

View File

@ -1,58 +0,0 @@
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

View File

@ -1,4 +1,4 @@
Loading and Oganising YAP Programs {#load_files}
Loading and Organising YAP Programs {#load_files}
===================================
Next, we present the main predicates and directives available to load
@ -8,4 +8,8 @@ Loading and Oganising YAP Programs {#load_files}
+ @ref YAPConsulting
+ @ref QLY
+ @ref QLY
+ @ref YAPBigLoad

View File

@ -1,4 +1,4 @@
The YAP Module system {#YAPModules}
The YAP Module system {#YAPModules}
=====================
The YAP module system is based on the Quintus/SISCtus module
@ -8,6 +8,15 @@ 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.
Next, we present:
+ @ref IntroModules
+ @ref ExplicitNaming
+ @ref ModuleBuiltins
+ @ref YAPMetaPredicates
### Using Modules in YAP {#IntroModules}
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.

View File

@ -1,9 +1,9 @@
YAP packages files {packages}
==============================
YAP packages {#packages}
============
+ @subpage real
+ @subpage bdds
+ @subpage BDDs
+ @subpage gecode
@ -26,5 +26,3 @@ YAP packages files {packages}
+ @subpage chr
+ @subpage clpqr

View File

@ -1,10 +0,0 @@
Programming in YAP {#YAPProgramming}
====================
+ @subpage YAPSyntax
+ @ref YAPCompilerSettings
+ @ref Indexing
+ @ref Deb_Interaction

View File

@ -1,8 +1,6 @@
Compatibility with other Prolog systems {#swi_iso_c}
======================================
@ingroup YAPProgramming
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

View File

@ -1,15 +1,10 @@
YAP Syntax {#YAPSyntax}
============
@ingroup YAPProgrammming
We will describe the syntax of YAP at two levels. We first will
describe the syntax for Prolog terms. In a second level we describe
the tokens from which Prolog terms are
built.
@defgroup Formal_Syntax Syntax of Terms
@ingroup YAPSyntax
### Syntax of Terms {#Formal_Syntax}
Below, we describe the syntax of YAP terms from the different
classes of tokens defined above. The formalism used will be <em>BNF</em>,
@ -84,17 +79,15 @@ dot with single quotes.
# @defgroup Tokens Prolog Tokens
@ingroup YAPSyntax
### Prolog Tokens {#Tokens}
Prolog tokens are grouped into the following categories:
## @defgroup Numbers Numbers
@ingroup Tokens
#### Numbers {#Numbers}
Numbers can be further subdivided into integer and floating-point numbers.
### @defgroup Integers Integers
##### @defgroup Integers {#Integers}
@ingroup Numbers
Integer numbers
@ -142,7 +135,7 @@ the word size of the machine. This is 32 bits in most current machines,
but 64 in some others, such as the Alpha running Linux or Digital
Unix. The scanner will read larger or smaller integers erroneously.
### @defgroup Floats Floats
##### Floats {#Floats}
@ingroup Numbers
Floating-point numbers are described by:
@ -167,7 +160,7 @@ Examples:
Floating-point numbers are represented as a double in the target
machine. This is usually a 64-bit number.
## Strings @defgroup Strings Character Strings
#### Strings Character Strings {#Strings}
Strings are described by the following rules:
@ -237,8 +230,7 @@ versions of YAP up to 4.2.0. Escape sequences can be disabled by using:
:- yap_flag(character_escapes,false).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
## @addgroup Atoms Atoms
@ingroup Tokens
#### Atoms {#Atoms}
Atoms are defined by one of the following rules:
@ -309,7 +301,8 @@ Punctuation tokens consist of one of the following characters:
These characters are used to group terms.
@subsection Layout Layout
#### Layout {#Layout}
Any characters with ASCII code less than or equal to 32 appearing before
a token are ignored.
@ -321,8 +314,8 @@ layout characters, the YAP parser behaves as if it had found a
single blank character. The end of a file also counts as a blank
character for this purpose.
## @addgroup WideChars Encoding Wide Character Support
@ingroup YAPSyntax
#### Wide Character Support {#WideChars}
@ingroup YAP]Syntax
YAP now implements a SWI-Prolog compatible interface to wide
@ -462,8 +455,7 @@ Prolog escape sequences while other streams generate an I/O exception.
=== @addgroup BOM BOM: Byte Order Mark
@ingroup WideChars
##### BOM: Byte Order Mark {#BOM}
From Stream Encoding, you may have got the impression that
text-files are complicated. This section deals with a related topic,
@ -483,8 +475,7 @@ writing, writing a BOM can be requested using the option
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
### Summary of YAP Predefined Operators {#ops}
The Prolog syntax caters for operators of three main kinds:

View File

@ -23,11 +23,11 @@ The manual is organised as follows:
+ @subpage load_files
+ @subpage builtins
+ @ref builtins
+ @subpage extensions
+ @ref extensions
+ @subpage library
+ @ref library
+ @subpage packages
@ -58,3 +58,51 @@ 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.
@defgroup builtins YAP Core Built-ins
@{}
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 Prolog also known as ISO-Prolog.
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" - 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.
@}
@defgroup 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.
@defgroup attributes Attributed Variables and Coroutining
@{
@subpage atts
@copydoc atts
}
@}
@defgroup YAPProgramming Programming in YAP
@{
@defgroup YAPSyntax Prolog Syntax
@subpage syntax
@copydoc syntax
@}
@}

View File

@ -225,69 +225,72 @@ typedef enum {
#define YAP_BOOT_MODE 2
typedef struct yap_boot_params {
/* boot type as suggested by the user */
//> boot type as suggested by the user
YAP_file_type_t boot_file_type;
/* if NON-NULL, path where we can find the saved state */
//> if NON-NULL, path where we can find the saved state
const char *SavedState;
/* if NON-0, minimal size for Heap or Code Area */
//> if NON-0, minimal size for Heap or Code Area
size_t HeapSize;
/* if NON-0, maximal size for Heap or Code Area */
//> if NON-0, maximal size for Heap or Code Area
size_t MaxHeapSize;
/* if NON-0, minimal size for Local+Global Stack */
//> if NON-0, minimal size for Local+Global Stack
size_t StackSize;
/* if NON-0, maximal size for Local+Global Stack */
//> if NON-0, maximal size for Local+Global Stack
size_t MaxStackSize;
//*> deprecated
size_t MaxGlobalSize;
/* if NON-0, minimal size for Trail */
//> if NON-0, minimal size for Trail
size_t TrailSize;
/* if NON-0, maximal size for Trail */
//> if NON-0, maximal size for Trail
size_t MaxTrailSize;
/* if NON-0, minimal size for AttributeVarStack */
//> if NON-0, minimal size for AttributeVarStack
size_t AttsSize;
/* if NON-0, maximal size for AttributeVarStack */
//> if NON-0, maximal size for AttributeVarStack
size_t MaxAttsSize;
/* if NON-NULL, value for YAPLIBDIR */
const char *YapLibDir;
/* if NON-NULL, name for a Prolog file to use when booting */
//> if NON-NULL, value for YAPLIBDIR
const char *YapLibDir;
//> if NON-NULL, value for YAPSSHAREDIR, that is, default value for libraries
const char *YapShareDir;
//> if NON-NULL, name for a Prolog file to use when booting
const char *YapPrologBootFile;
/* if NON-NULL, name for a Prolog file to use when initializing */
//> if NON-NULL, name for a Prolog file to use when initializing
const char *YapPrologInitGoal;
/* if NON-NULL, name for a Prolog file to consult before entering top-level */
//> if NON-NULL, name for a Prolog file to consult before entering top-level
const char *YapPrologRCFile;
/* if NON-NULL, a goal to run before top-level */
//> if NON-NULL, a goal to run before top-level
const char *YapPrologGoal;
/* if NON-NULL, a goal to run as top-level */
//> if NON-NULL, a goal to run as top-level
const char *YapPrologTopLevelGoal;
/* if NON-NULL, a path to extend file-search-path */
//> if NON-NULL, a path to extend file-search-path
const char *YapPrologAddPath;
/* if previous NON-NULL and TRUE, halt after consulting that file */
//> if previous NON-NULL and TRUE, halt after consulting that file
bool HaltAfterConsult;
/* ignore .yaprc, .prolog.ini, etc. files. */
//> ignore .yaprc, .prolog.ini, etc. files.
bool FastBoot;
/* the next field only interest YAPTAB */
/* if NON-0, maximum size for Table Space */
//> the next field only interest YAPTAB
//> if NON-0, maximum size for Table Space
size_t MaxTableSpaceSize;
/* the next three fields only interest YAPOR, but we keep them so that
users don't need to recompile DLL in order to use YAPOR */
/* if NON-0, number of workers we want to have (default=1) */
//> if NON-0, number of workers we want to have (default=1)
unsigned long int NumberWorkers;
/* if NON-0, manage the inner scheduler loop (default = 10) */
//> if NON-0, manage the inner scheduler loop (default = 10)
unsigned long int SchedulerLoop;
/* if NON-0, say how long to keep nodes (default = 3) */
//> if NON-0, say how long to keep nodes (default = 3)
unsigned long int DelayedReleaseLoad;
/* end of YAPOR fields */
//> end of YAPOR fields
/* whether Prolog should handle interrupts. Note that
interrupts will always be disabled in embedded mode. */
bool PrologCannotHandleInterrupts;
/* flag for JIT mode */
//> flag for JIT mode
int ExecutionMode;
/* number of arguments that Prolog will see */
//> number of arguments that Prolog will see
int Argc;
/* array of arguments as seen by Prolog */
//> array of arguments as seen by Prolog
char **Argv;
/* embedded in some other system: no signals, readline, etc */
//> embedded in some other system: no signals, readline, etc
bool Embedded;
/* QuietMode */
//> QuietMode
int QuietMode;
/* nf: Begin ypp preprocessor code */
@ -298,9 +301,9 @@ typedef struct yap_boot_params {
/* End preprocessor code */
#ifdef MYDDAS_MYSQL
/* If any myddas option was given */
//> If any myddas option was given
short myddas;
/* MYDDAS Fields */
//> MYDDAS Fields
char *myddas_user;
char *myddas_pass;
char *myddas_db;
@ -308,7 +311,7 @@ typedef struct yap_boot_params {
#endif
/* errornumber */
int ErrorNo;
/* errorstring */
//> errorstring
char *ErrorCause;
} YAP_init_args;

View File

@ -61,6 +61,9 @@ set (POSITION_INDEPENDENT_CODE TRUE)
chartypes.yap
)
add_to_group( pl_os_library YAPOS_PL_SOURCES )
if (ANDROID)
file(INSTALL ${YAPOS_PL_SOURCES} DESTINATION ${libpl}/os)
else()

View File

@ -268,7 +268,7 @@ p_code_type( LOWER , lower) :-
p_code_type( LOWER, lower( Upper)) :-
toupper( LOWER, Upper),
code_type_lower( LOWER ).
vp_code_type( LOWER, to_lower( Upper)) :-
p_code_type( LOWER, to_lower( Upper)) :-
toupper( LOWER, Upper).
p_code_type( UPPER, upper ) :-
code_type_upper( UPPER ).

View File

@ -1,4 +1,4 @@
CHR: Constraint Handling Rules {#chr}
patttCHR: Constraint Handling Rules {#chr}
==============================

View File

@ -1,19 +1,11 @@
The MYDDAS Data-base interface {#myddas}
===============================
@ingroup Packages
@{
@file myddas.md
The MYDDAS database project was developed within a FCT project aiming at
the development of a highly efficient deductive database system, based
on the coupling of the MySQL relational database system with the YAP
Prolog system. MYDDAS was later expanded to support the ODBC interface.
@defgroup Requirements_and_Installation_Guide Requirements and Installation Guide
@ingroup #myddas
### Requirements and Installation Guide {#Requirements_and_Installation_Guide}
Next, we describe how to usen of the YAP with the MYDDAS System. The
use of this system is entirely depend of the MySQL development libraries
@ -44,9 +36,7 @@ The MYDDAS Data-base interface {#myddas}
This option is only available in MySQL. It enables the option to interact with the MySQL server in
two different ways. As if we were on the MySQL Client Shell, and as if
we were using Datalog.
@defgroup MYDDAS_Architecture MYDDAS Architecture
@ingroup myddas
### MYDDAS Architecture {#MYDDAS_Architecture}
The system includes four main blocks that are put together through the
MYDDAS interface: the Yap Prolog compiler, the MySQL database system, an
@ -95,8 +85,8 @@ The MYDDAS Data-base interface {#myddas}
FROM 'phonebook' A
WHERE A.Name = 'John Doe';
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@defgroup View_Level_Interface View Level Interface
@ingroup myddas
### View Level Interface {#View_Level_Interface}
@pred db view(+,+,+).
@ -188,8 +178,7 @@ The MYDDAS Data-base interface {#myddas}
To know how to use db `view/3`, please refer to Draxler's Prolog to
SQL Compiler Manual.
@defgroup Accessing_Tables_in_Data_Sources_Using_SQL Accessing Tables in Data Sources Using SQL
@ingroup myddas
### Accessing Tables in Data Sources Using SQL {#Accessing_Tables_in_Data_Sources_Using_SQL}
@pred db_sql(+,+,?).
@ -216,9 +205,7 @@ The MYDDAS Data-base interface {#myddas}
?- db_sql('SELECT * FROM phonebook',LA).
LA = ['D','John Doe',123456789] ?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@defgroup Insertion_of_Rows Insertion of Rows
@ingroup myddas
@ingroup MYDDAS
### Insertion of Rows {#Insertion_of_Rows}
@pred db_assert(+,+).
@pred db_assert(+).
@ -264,9 +251,7 @@ The MYDDAS Data-base interface {#myddas}
Would insert the row: `A,null value,31` into the relation
`Hello World`, assuming that the second row allows null values.
*/
/** @pred db insert(+,+,+).
@pred db insert(+,+,+).
@pred db insert(+,+).
@ -289,8 +274,7 @@ The MYDDAS Data-base interface {#myddas}
?- helloWorldInsert('A',NULL,31).
yes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@defgroup Types_of_Attributes Types of AttributesL
@ingroup myddas
### Types of AttributesL {#Types_of_Attributes}
@pred db_get_attributes_types(+,+,?).
@ -321,8 +305,7 @@ The MYDDAS Data-base interface {#myddas}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
where <tt>Hello World</tt> is the name of the relation and <tt>myddas</tt> is the
connection identifier.
@defgroup Number_of_Fields Number of Fields
@ingroup myddas
### Number of Fields {#Number_of_Fields}
@pred db_number_of_fields(+,?).
@ -348,9 +331,7 @@ The MYDDAS Data-base interface {#myddas}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
where `Hello World` is the name of the
relation and `myddas` is the connection identifier.
@defgroup Describing_a_Relation Describing a Relation
@ingroup #myddas
### Describing a Relation {#Describing_a_Relation}
@pred db_datalog_describe(+,+).
@pred db_datalog_describe(+).
@ -391,8 +372,7 @@ The MYDDAS Data-base interface {#myddas}
Term = tableInfo('Letter',char(1),'YES','',null(2),'') ? ;
no
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@defgroup Enumerating_Relations Enumeration Relations Describing_a_Relation Describing a Relation
@ingroup #myddas
### Enumeration Relations Describing_a_Relation Describing a Relation {#Enumerating_Relations}
/@pred db_datalog_show_tables(+).
@ -431,10 +411,7 @@ The MYDDAS Data-base interface {#myddas}
Table = table('Hello World') ? ;
no
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@defgroup The_MYDDAS_MySQL_Top_Level The MYDDAS MySQL Top Level
@ingroup #myddas
### The MYDDAS MySQL Top Level {#The_MYDDAS_MySQL_Top_Level}
@pred db_top_level(+,+,+,+,+).
@pred db_top_level(+,+,+,+).
@ -484,9 +461,7 @@ The MYDDAS Data-base interface {#myddas}
yes
?-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@defgroup Other_MYDDAS_Properties Other MYDDAS Properties
@ingroup #myddas
### Other MYDDAS Properties {#Other_MYDDAS_Properties}
@pred db_verbose(+).

View File

@ -18,6 +18,6 @@ Object = 'http://www.example.org/tv_show',
Predicate = 'http://www.w3.org/1999/02/22-rdf-syntax-ns#type',
Subject = 'http://www.example.org/law_and_order_ci' ?
~~~~{.prolog}
~~~~
The code also includes a library under developent to connect Yap and libXML2.

View File

@ -18,9 +18,14 @@ if (LIBR_FOUND)
set (REAL_SOURCES
real.c
real.pl
)
set (REAL_PL
real.pl
)
add_to_group( pl_library REAL_PL )
include_directories (
${CMAKE_CURRENT_BINARY_DIR}
${LIBR_INCLUDE_DIRS}
@ -33,8 +38,10 @@ include_directories (
add_library (real SHARED ${REAL_SOURCES})
target_link_libraries (real ${LIBR_LIBRARIES} ${CMAKE_DL_LIBS} libYap)
target_link_libraries (real ${LIBR_LIBRARIES} libYap)
check_include_files( "stdio.h;R.h" HAVE_R_H )
check_include_files( "R.h;Rembedded.h" HAVE_R_EMBEDDED_H )
check_include_files( "Rembedded.h;Rinterface.h" HAVE_R_INTERFACE_H )
configure_file ("rconfig.h.cmake" "rconfig.h" )

View File

@ -43,8 +43,7 @@ The main modes for utilising the interface are
Pass Prolog data to R, pass R data to Prolog or assign an R expression to
an assignable R expression.
@defgroup TestingR Testing Real
### Testing Real {#TestingR}
There is a raft of examples packed in a singl```e file that test the library.
@ -55,8 +54,7 @@ There is a raft of examples packed in a singl```e file that test the library.
?- edit( pack(real/examples/for_real) ).
~~~~
@defgroup RSyntax Prolog and R Syntax
### Prolog and R Syntax {#RSyntax}
There are syntactic conventions in R that make unparsable prolog code.
Notably function and variable names are allowed to contain dots, square brackets are used
@ -77,8 +75,7 @@ Prolog constructs are converted by the library as follows:
* Expressions that pose difficulty in translation can always be passed as unquoted Prolog atoms or strings.
]]* since 0:1:2 foo() is valid syntax: =|<- dev..off() |= works now (with no need for dev..off(.))
* since 0:1:2 mat[1] is valid syntax: =|m[1] <- 4|= works now (with no need for m^[...])
@defgroup RDataTransfer Mapping Data betweenn Prolog and R
### Mapping Data betweenn Prolog and R {#RDataTransfer}
R vectors are mapped to prolog lists and matrices are mapped to nested lists.
The convention works the other way around too.
@ -159,8 +156,7 @@ This is only advisable for short data structures. For instance,
Through this interface it is more convenient to be explicit about R chars by Prolog prepending
atoms or codes with + as in the above example.
@defgroup RealExamples Examples
### Examples {#RealExamples}
~~~~