diff --git a/C/attvar.c b/C/attvar.c index 09bcbe8c3..470d35062 100644 --- a/C/attvar.c +++ b/C/attvar.c @@ -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 diff --git a/CMakeLists.txt b/CMakeLists.txt index aef88b428..726243473 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -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( diff --git a/H/YapGFlagInfo.h b/H/YapGFlagInfo.h index 2575880cb..e38c65af8 100644 --- a/H/YapGFlagInfo.h +++ b/H/YapGFlagInfo.h @@ -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`. */ +//! @} diff --git a/docs/CMakeLists.txt b/docs/CMakeLists.txt index 79852fd55..d3b15361d 100644 --- a/docs/CMakeLists.txt +++ b/docs/CMakeLists.txt @@ -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() diff --git a/docs/Doxyfile.in b/docs/Doxyfile.in index a98df128f..a2ba3d457 100644 --- a/docs/Doxyfile.in +++ b/docs/Doxyfile.in @@ -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 diff --git a/docs/md/attributes.md b/docs/md/attributes.md deleted file mode 100644 index cc1f68ec1..000000000 --- a/docs/md/attributes.md +++ /dev/null @@ -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 atts 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 -attribute_goal/2 converts from an attribute to a goal. - -+ The user-defined predicate -project_attributes/2 is used from a set of variables into a set of -constraints or goals. One application of project_attributes/2 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 name which is private 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 + and - unary -operators. The prefix + 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 depends 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 domain, 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 - - -@} - -@} diff --git a/docs/md/bdd.md b/docs/md/bdd.md deleted file mode 100644 index c087b90c5..000000000 --- a/docs/md/bdd.md +++ /dev/null @@ -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 diff --git a/docs/md/builtins.md b/docs/md/builtins.md deleted file mode 100644 index bcfad0408..000000000 --- a/docs/md/builtins.md +++ /dev/null @@ -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. - diff --git a/docs/md/download.md b/docs/md/download.md deleted file mode 100644 index 927514b0f..000000000 --- a/docs/md/download.md +++ /dev/null @@ -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. diff --git a/docs/md/extensions.md b/docs/md/extensions.md index 70cf92da7..55ca22144 100644 --- a/docs/md/extensions.md +++ b/docs/md/extensions.md @@ -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 diff --git a/docs/md/fli.md b/docs/md/fli.md index f45c1b53d..03f085e8f 100644 --- a/docs/md/fli.md +++ b/docs/md/fli.md @@ -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: They return the number of integers scanned, up to a maximum of sz, and -1 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: 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}