docs
This commit is contained in:
parent
a6e6642eb2
commit
6e7846e210
@ -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
|
||||
|
@ -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(
|
||||
|
@ -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`.
|
||||
*/
|
||||
//! @}
|
||||
|
@ -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()
|
||||
|
||||
|
@ -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
|
||||
|
@ -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
|
||||
|
||||
|
||||
@}
|
||||
|
||||
@}
|
@ -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
|
@ -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.
|
||||
|
@ -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.
|
@ -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
|
||||
|
@ -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
|
||||
|
@ -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
|
@ -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
|
||||
|
||||
|
||||
|
@ -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.
|
||||
|
@ -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
|
||||
|
||||
|
||||
|
@ -1,10 +0,0 @@
|
||||
Programming in YAP {#YAPProgramming}
|
||||
====================
|
||||
|
||||
+ @subpage YAPSyntax
|
||||
|
||||
+ @ref YAPCompilerSettings
|
||||
|
||||
+ @ref Indexing
|
||||
|
||||
+ @ref Deb_Interaction
|
@ -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
|
||||
|
@ -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:
|
||||
|
||||
|
@ -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
|
||||
@}
|
||||
|
||||
|
||||
|
||||
@}
|
||||
|
||||
|
@ -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;
|
||||
|
||||
|
@ -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()
|
||||
|
@ -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 ).
|
||||
|
@ -1,4 +1,4 @@
|
||||
CHR: Constraint Handling Rules {#chr}
|
||||
patttCHR: Constraint Handling Rules {#chr}
|
||||
==============================
|
||||
|
||||
|
||||
|
@ -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(+).
|
||||
|
||||
|
@ -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.
|
||||
|
@ -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" )
|
||||
|
@ -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}
|
||||
|
||||
~~~~
|
||||
|
||||
|
Reference in New Issue
Block a user