docs
This commit is contained in:
parent
7063641a5b
commit
70232133cc
11
C/atomic.c
11
C/atomic.c
|
@ -18,11 +18,14 @@
|
|||
static char SccsId[] = "%W% %G%";
|
||||
#endif
|
||||
|
||||
/** @addgroup Predicates_on_Atoms Predicates on Atoms and Strings
|
||||
@ingroup YAPChars
|
||||
@{
|
||||
/**
|
||||
* @file atomic.c
|
||||
*
|
||||
* @defgroup Predicates_on_Atoms Predicates on Atoms and Strings
|
||||
* @ingroup builtins
|
||||
* @{
|
||||
|
||||
The following predicates are used to manipulate atoms:
|
||||
@brief The following predicates are used to manipulate atoms, strings, lists of codes and lists of chars:
|
||||
|
||||
\toc
|
||||
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
0/*************************************************************************
|
||||
/*************************************************************************
|
||||
* *
|
||||
* YAP Prolog *
|
||||
* *
|
||||
|
@ -30,9 +30,9 @@ static char SccsId[] = "%W% %G%";
|
|||
|
||||
/**
|
||||
@file attvar.c
|
||||
@{
|
||||
@defgroup AttributeVariables_Builtins Implementation of Attribute Declarations
|
||||
@ingroup AttributeVariables
|
||||
@{
|
||||
@ingroup attributes
|
||||
*/
|
||||
|
||||
#ifdef COROUTINING
|
||||
|
|
|
@ -17,7 +17,9 @@
|
|||
*************************************************************************/
|
||||
|
||||
/**
|
||||
@file c_interface.c
|
||||
* @file c_interface.c
|
||||
*
|
||||
* @addtogroup ChYInterface
|
||||
*/
|
||||
|
||||
#ifndef C_INTERFACE_C
|
||||
|
@ -175,11 +177,6 @@ X_API void YAP_SlotsToArgs(int HowMany, YAP_handle_t slot);
|
|||
|
||||
/// @}
|
||||
|
||||
/**
|
||||
@addtogroup c-interface
|
||||
@{
|
||||
*/
|
||||
|
||||
static arity_t current_arity(void) {
|
||||
CACHE_REGS
|
||||
if (P && PREVOP(P, Osbpp)->opc == Yap_opcode(_call_usercpred)) {
|
||||
|
|
2
C/init.c
2
C/init.c
|
@ -103,7 +103,7 @@ void *YAP_save;
|
|||
/**
|
||||
|
||||
@defgroup Operators Summary of YAP Predefined Operators
|
||||
@ingroup Syntax
|
||||
@ingroup YAPSyntax
|
||||
@{
|
||||
|
||||
The Prolog syntax caters for operators of three main kinds:
|
||||
|
|
|
@ -20,17 +20,14 @@ static char SccsId[] = "%W% %G%";
|
|||
|
||||
/**
|
||||
|
||||
@defgroup YAPSyntax YAP Syntax
|
||||
@ingroup YAPProgramming
|
||||
@{
|
||||
@addtogroup YAPSyntax
|
||||
|
||||
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 \a tokens from which Prolog \a terms are
|
||||
built.
|
||||
|
||||
@defgroup Formal_Syntax Syntax of Terms
|
||||
@ingroup Syntax
|
||||
@ingroup YAPSyntax
|
||||
@{
|
||||
|
||||
Below, we describe the syntax of YAP terms from the different
|
||||
|
|
|
@ -35,7 +35,7 @@
|
|||
/**
|
||||
|
||||
@defgroup Formal_Syntax Syntax of Terms
|
||||
@ingroup Syntax
|
||||
@ingroup YAPSyntax
|
||||
@{
|
||||
|
||||
|
||||
|
|
|
@ -17,7 +17,8 @@
|
|||
#ifdef SCCS
|
||||
static char SccsId[] = "@(#)utilpreds.c 1.3";
|
||||
#endif
|
||||
/** @addtogroup YAP_Terms
|
||||
/**
|
||||
* @addtogroup Terms
|
||||
|
||||
*/
|
||||
|
||||
|
@ -5405,4 +5406,3 @@ Replace every `$VAR( _I_)` by a free variable.
|
|||
Yap_InitCPred("dum", 1, camacho_dum, SafePredFlag);
|
||||
#endif
|
||||
}
|
||||
|
||||
|
|
|
@ -17,7 +17,7 @@
|
|||
|
||||
/** @file YapFlags.h
|
||||
|
||||
@ingroup Flags
|
||||
@addtogroup Flags
|
||||
*/
|
||||
|
||||
#ifndef YAP_FLAGS_H
|
||||
|
|
|
@ -17,25 +17,24 @@
|
|||
|
||||
/** @file YapGFlagInfo.h
|
||||
|
||||
@ingroup Flags
|
||||
@addtogroup YAPFlags
|
||||
*/
|
||||
|
||||
/** @pred yap_flag(? _Param_,? _Value_)
|
||||
/** @pred yap_flag( ?Param, ?Value)
|
||||
|
||||
|
||||
Set or read system properties for _Param_:
|
||||
|
||||
@enum YapGFlag Prolog
|
||||
@Brief global flag:
|
||||
|
||||
*/
|
||||
|
||||
/// `address_bits`
|
||||
///
|
||||
/// Number of address bits in the machine, either 64 or 32 bits.
|
||||
YAP_FLAG(ADDRESS_BITS_FLAG, "address_bits", false, nat, BITNESS, NULL)
|
||||
, /** `address_bits`
|
||||
YAP_FLAG(ADDRESS_BITS_FLAG, "address_bits", false, nat, BITNESS, NULL), /**< `address_bits`
|
||||
Number of address bits in the machine, either 64 or 32 bits */
|
||||
YAP_FLAG(AGC_MARGIN_FLAG, "agc_margin", true, nat, "10000",
|
||||
agc_threshold), /**`agc_margin `
|
||||
|
||||
YAP_FLAG(AGC_MARGIN_FLAG, "agc_margin", true, nat, "10000",
|
||||
agc_threshold), /**< `agc_margin`
|
||||
An integer: if this amount of atoms has been created since the last
|
||||
atom-garbage collection, perform atom garbage collection at the first
|
||||
opportunity. Initial value is 10,000. May be changed. A value of 0
|
||||
|
|
|
@ -17,12 +17,12 @@
|
|||
|
||||
/** @file YapLFlagInfo.h
|
||||
|
||||
@ingroup Flags
|
||||
@addtogroup Flags
|
||||
*/
|
||||
|
||||
YAP_FLAG( AUTOLOAD_FLAG, "autoload", true, booleanFlag, "false" , NULL ),
|
||||
YAP_FLAG( BREAK_LEVEL_FLAG, "break_level", true, nat, "0" , NULL ),
|
||||
YAP_FLAG( CALL_COUNTING_FLAG, "call_counting", true, booleanFlag, "true" , NULL ), /**< `call_counting`
|
||||
YAP_FLAG( CALL_COUNTING_FLAG, "call_counting", true, booleanFlag, "true" , NULL ), /** + `call_counting`
|
||||
|
||||
Predicates compiled with this flag set maintain a counter on the numbers of proceduree calls and of retries. These counters are decreasing counters, and they can be used as timers. Three counters are available:
|
||||
|
||||
|
@ -36,16 +36,16 @@ YAP_FLAG( CALL_COUNTING_FLAG, "call_counting", true, booleanFlag, "true" , NULL
|
|||
`fileerrors` is disabled.
|
||||
*/
|
||||
YAP_FLAG( ENCODING_FLAG, "encoding", true, isatom, "utf-8" , getenc ),
|
||||
YAP_FLAG( FILEERRORS_FLAG, "fileerrors", true, booleanFlag, "true" , NULL ), /**< `fileerrors`
|
||||
YAP_FLAG( FILEERRORS_FLAG, "fileerrors", true, booleanFlag, "true" , NULL ), /** + `fileerrors`
|
||||
|
||||
If `on` `fileerrors` is `on`, if `off` (default)
|
||||
`fileerrors` is disabled.
|
||||
*/
|
||||
YAP_FLAG( LANGUAGE_MODE_FLAG, "language_mode", true, isatom, "yap" , NULL ), /**< `language_mode`
|
||||
YAP_FLAG( LANGUAGE_MODE_FLAG, "language_mode", true, isatom, "yap" , NULL ), /** + `language_mode`
|
||||
|
||||
wweter native mode or trying to emulate a different Prolog.
|
||||
*/
|
||||
YAP_FLAG( REDEFINE_WARNINGS_FLAG, "redefine_warnings", true, booleanFlag, "true" , NULL ), /**< `redefine_warnings `
|
||||
YAP_FLAG( REDEFINE_WARNINGS_FLAG, "redefine_warnings", true, booleanFlag, "true" , NULL ), /** + `redefine_warnings `
|
||||
|
||||
If _Value_ is unbound, tell whether warnings for procedures defined
|
||||
in several different files are `on` or
|
||||
|
@ -53,17 +53,17 @@ in several different files are `on` or
|
|||
and if it is bound to `off` disable them. The default for YAP is
|
||||
`off`, unless we are in `sicstus` or `iso` mode.
|
||||
*/
|
||||
YAP_FLAG( SINGLE_VAR_WARNINGS_FLAG, "single_var_warnings", true, booleanFlag, "true" , NULL ), /**< `single_var_warnings`
|
||||
YAP_FLAG( SINGLE_VAR_WARNINGS_FLAG, "single_var_warnings", true, booleanFlag, "true" , NULL ), /** + `single_var_warnings`
|
||||
If `true` (default `true`) YAP checks for singleton variables when loading files. A singleton variable is a variable that appears ony once in a clause. The name must start with a capital letter, variables whose name starts with underscore are never considered singleton.
|
||||
|
||||
*/
|
||||
YAP_FLAG( STACK_DUMP_ON_ERROR_FLAG, "stack_dump_on_error", true, booleanFlag, "false" , NULL ), /**< `stack_dump_on_error `
|
||||
YAP_FLAG( STACK_DUMP_ON_ERROR_FLAG, "stack_dump_on_error", true, booleanFlag, "false" , NULL ), /** + `stack_dump_on_error `
|
||||
|
||||
If `true` show a stack dump when YAP finds an error. The default is
|
||||
`off`.
|
||||
*/
|
||||
YAP_FLAG( STREAM_TYPE_CHECK_FLAG, "stream_type_check", true, isatom, "loose" , NULL ),
|
||||
YAP_FLAG( SYNTAX_ERRORS_FLAG, "syntax_errors", true, synerr, "error" , NULL ), /**< `syntax_errors`
|
||||
YAP_FLAG( SYNTAX_ERRORS_FLAG, "syntax_errors", true, synerr, "error" , NULL ), /** + `syntax_errors`
|
||||
|
||||
Control action to be taken after syntax errors while executing read/1,
|
||||
`read/2`, or `read_term/3`:
|
||||
|
@ -76,14 +76,14 @@ Report the syntax error and generate an error (default).
|
|||
+ `quiet`
|
||||
Just fail
|
||||
*/
|
||||
YAP_FLAG( TYPEIN_MODULE_FLAG, "typein_module", true, isatom, "user" , typein ), /**< `typein_module `
|
||||
YAP_FLAG( TYPEIN_MODULE_FLAG, "typein_module", true, isatom, "user" , typein ), /** + `typein_module `
|
||||
|
||||
If bound, set the current working or type-in module to the argument,
|
||||
which must be an atom. If unbound, unify the argument with the current
|
||||
working module.
|
||||
|
||||
*/
|
||||
YAP_FLAG( USER_ERROR_FLAG, "user_error", true, stream, "user_error" , set_error_stream ), /**< `user_error1`
|
||||
YAP_FLAG( USER_ERROR_FLAG, "user_error", true, stream, "user_error" , set_error_stream ), /** + `user_error1`
|
||||
|
||||
If the second argument is bound to a stream, set user_error to
|
||||
this stream. If the second argument is unbound, unify the argument with
|
||||
|
|
6
H/qly.h
6
H/qly.h
|
@ -21,8 +21,10 @@
|
|||
*
|
||||
* @file qly.h
|
||||
*
|
||||
|
||||
* @defgroup SaveRestoreSupport C-support for saved states.
|
||||
* @ingroup YAPSaving
|
||||
* @ingroup QLY
|
||||
* @{
|
||||
*
|
||||
*/
|
||||
|
||||
|
@ -137,3 +139,5 @@ typedef enum {
|
|||
|
||||
#define AllocTempSpace() (HR)
|
||||
#define EnoughTempSpace(sz) ((ASP - HR) * sizeof(CELL) > sz)
|
||||
|
||||
/// @} @}
|
||||
|
|
|
@ -1356,9 +1356,9 @@
|
|||
|
||||
|
||||
answer_resolution:
|
||||
INIT_PREFETCH()
|
||||
dep_fr_ptr dep_fr;
|
||||
ans_node_ptr ans_node;
|
||||
INIT_PREFETCH();
|
||||
|
||||
OPTYAP_ERROR_CHECKING(answer_resolution, SCH_top_shared_cp(B) && B->cp_or_fr->alternative != ANSWER_RESOLUTION);
|
||||
OPTYAP_ERROR_CHECKING(answer_resolution, !SCH_top_shared_cp(B) && B->cp_ap != ANSWER_RESOLUTION);
|
||||
|
@ -1664,6 +1664,7 @@
|
|||
#ifdef THREADS_CONSUMER_SHARING
|
||||
goto answer_resolution_completion;
|
||||
#endif /* THREADS_CONSUMER_SHARING */
|
||||
INIT_PREFETCH()
|
||||
dep_fr_ptr dep_fr;
|
||||
ans_node_ptr ans_node;
|
||||
#ifdef YAPOR
|
||||
|
@ -1671,7 +1672,6 @@
|
|||
long timestamp = 0;
|
||||
#endif /* TIMESTAMP_CHECK */
|
||||
int entry_owners = 0;
|
||||
INIT_PREFETCH();
|
||||
|
||||
if (SCH_top_shared_cp(B)) {
|
||||
#ifdef TIMESTAMP_CHECK
|
||||
|
|
|
@ -3,9 +3,6 @@
|
|||
![The YAP Logo](docs/icons/yap_128x128x32.png)
|
||||
</center>
|
||||
|
||||
User Manual for YAP6 (#main)
|
||||
====================
|
||||
|
||||
NOTE: this version of YAP is still experimental, documentation may be out of date.
|
||||
|
||||
## Introduction
|
||||
|
@ -39,6 +36,10 @@ Springer-Verlag.
|
|||
YAP 6.3.4 has been built with the gcc and clang compilers on Linux and OSX machines. We expect to recover support for WIN32 machines and
|
||||
Android next.
|
||||
|
||||
We are happy to include in YAP several excellent packages developed
|
||||
under separate licenses. Our thanks to the authors for their kind
|
||||
authorization to include these packages.
|
||||
|
||||
The overall copyright and permission notice for YAP4.3 can be found in
|
||||
the Artistic file in this directory. YAP follows the Perl Artistic
|
||||
license, and it is thus non-copylefted freeware. Some components of YAP have been obtained from SWI Prolog and ciao, and have
|
||||
|
@ -54,10 +55,6 @@ On-line documentation is available for [YAP](http://www.dcc.fp.pt/~vsc/yap/)
|
|||
|
||||
|
||||
|
||||
We are happy to include in YAP several excellent packages developed
|
||||
under separate licenses. Our thanks to the authors for their kind
|
||||
authorization to include these packages.
|
||||
|
||||
The packages are, in alphabetical order:
|
||||
|
||||
+ The CHR package developed by Tom Schrijvers,
|
|
@ -1,4 +1,4 @@
|
|||
/****************************************************************************
|
||||
l/****************************************************************************
|
||||
**
|
||||
** Copyright (C) 2012 Denis Shienkov <denis.shienkov@gmail.com>
|
||||
** Copyright (C) 2012 Laszlo Papp <lpapp@kde.org>
|
||||
|
|
|
@ -522,14 +522,14 @@ CASE_SENSE_NAMES = NO
|
|||
# scope will be hidden.
|
||||
# The default value is: NO.
|
||||
|
||||
HIDE_SCOPE_NAMES = NO
|
||||
HIDE_SCOPE_NAMES = YES
|
||||
|
||||
# If the HIDE_COMPOUND_REFERENCE tag is set to NO (default) then doxygen will
|
||||
# append additional text to a page's title, such as Class Reference. If set to
|
||||
# YES the compound reference will be hidden.
|
||||
# The default value is: NO.
|
||||
|
||||
HIDE_COMPOUND_REFERENCE= NO
|
||||
HIDE_COMPOUND_REFERENCE= YES
|
||||
|
||||
# If the SHOW_INCLUDE_FILES tag is set to YES then doxygen will put a list of
|
||||
# the files that are included by a file in the documentation of that file.
|
||||
|
@ -775,7 +775,8 @@ WARN_LOGFILE =
|
|||
# spaces. See also FILE_PATTERNS and EXTENSION_MAPPING
|
||||
# Note: If this tag is empty the current directory is searched.
|
||||
|
||||
INPUT = @PROJECT_SOURCE_DIR@/pl \
|
||||
INPUT = @PROJECT_SOURCE_DIR@/INSTALL.md \
|
||||
@PROJECT_SOURCE_DIR@/pl \
|
||||
@PROJECT_SOURCE_DIR@/CXX \
|
||||
@PROJECT_SOURCE_DIR@/OPTYap \
|
||||
@PROJECT_SOURCE_DIR@/C \
|
||||
|
@ -784,9 +785,8 @@ INPUT = @PROJECT_SOURCE_DIR@/pl \
|
|||
@PROJECT_SOURCE_DIR@/os \
|
||||
@PROJECT_SOURCE_DIR@/library \
|
||||
@PROJECT_SOURCE_DIR@/packages \
|
||||
@PROJECT_SOURCE_DIR@/swi/library
|
||||
# @PROJECT_SOURCE_DIR@/docs/md \
|
||||
# @PROJECT_SOURCE_DIR@/INSTALL.md
|
||||
@PROJECT_SOURCE_DIR@/swi/library \
|
||||
@PROJECT_SOURCE_DIR@/docs/md \
|
||||
|
||||
|
||||
# This tag can be used to specify the character encoding of the source files
|
||||
|
@ -844,6 +844,7 @@ EXCLUDE = *pltotex.pl \
|
|||
@PROJECT_SOURCE_DIR@/packages/CLPBN/examples \
|
||||
@PROJECT_SOURCE_DIR@/packages/prosqlite \
|
||||
@PROJECT_SOURCE_DIR@/packages/pyswip \
|
||||
@PROJECT_SOURCE_DIR@/library/dialect/swi/os
|
||||
|
||||
|
||||
# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or
|
||||
|
@ -860,7 +861,13 @@ EXCLUDE_SYMLINKS = NO
|
|||
# Note that the wildcards are matched against the file with absolute path, so to
|
||||
# exclude all test directories for example use the pattern */test/*
|
||||
|
||||
EXCLUDE_PATTERNS = */CMakeFiles/* *~
|
||||
EXCLUDE_PATTERNS = \
|
||||
@PROJECT_SOURCE_DIR@/packages/gecode/gecode3_yap.cc \
|
||||
@PROJECT_SOURCE_DIR@/packages/gecode/gecode4_yap.cc \
|
||||
@PROJECT_SOURCE_DIR@/packages/gecode/gecode3.yap \
|
||||
@PROJECT_SOURCE_DIR@/packages/gecode/gecode4.yap \
|
||||
@PROJECT_SOURCE_DIR@/packages/gecode/gecode3_yap_hand_written.yap \ @PROJECT_SOURCE_DIR@/packages/gecode/gecode4_yap_hand_written.yap
|
||||
*/CMakeFiles/* *~ */\#* \
|
||||
|
||||
# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
|
||||
# (namespaces, classes, functions, etc.) that should be excluded from the
|
||||
|
@ -2044,7 +2051,11 @@ SEARCH_INCLUDES = YES
|
|||
# This tag requires that the tag SEARCH_INCLUDES is set to YES.
|
||||
|
||||
INCLUDE_PATH = @CMAKE_BINARY_DIR@ \
|
||||
@CMAKE_BINARY_DIR@/packages/gecode
|
||||
@PROJECT_SOURCE_DIR@/H \
|
||||
@PROJECT_SOURCE_DIR@/H/generated \
|
||||
@PROJECT_SOURCE_DIR@/include \
|
||||
@PROJECT_SOURCE_DIR@/os \
|
||||
@PROJECT_SOURCE_DIR@/OPTYap \
|
||||
|
||||
# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
|
||||
# patterns (like *.h and *.hpp) to filter out the header-files in the
|
||||
|
|
|
@ -5,8 +5,8 @@ Installing YAP {#install}
|
|||
|
||||
### Downloading YAP {#download}
|
||||
|
||||
The latest development version of Yap-6 is available source-only through GIT repositories. The main references
|
||||
repository is at
|
||||
The latest development version of Yap-6 is available source-only
|
||||
through GIT repositories. The main reference repository is at
|
||||
|
||||
+ [github](https://github.com/vscosta/yap-6.3)
|
||||
|
||||
|
@ -16,7 +16,7 @@ We store an older version of YAP at:
|
|||
|
||||
Please just use `git clone` to obtain the distribution. Ie, to download YAP from the command line please type:
|
||||
|
||||
~~~~=
|
||||
~~~~~
|
||||
git clone https://github.com/vscosta/yap-6.3 yap-6.3
|
||||
~~~~~
|
||||
|
||||
|
@ -26,15 +26,15 @@ The first argument is the repository, the last argument is the (optional) target
|
|||
|
||||
#### Download Options
|
||||
|
||||
More detailed, maybe useful information:
|
||||
It may be useful to know:
|
||||
|
||||
+ If you are have limited bandwith or disk room, consider using
|
||||
+ If you are have limited bandwith or disk spaceq, consider using
|
||||
`git clone --depth XX` to only include the last `XX` commits.
|
||||
|
||||
+ Older versions of YAP were distributed with modules. YAP-6.3.5 is
|
||||
a single package, and it does not need `git submodule`.
|
||||
|
||||
+ The GitHub site includes a number of companion packages,
|
||||
+ The GitHub site includes a number of companion packages for YAP,
|
||||
including [doxygen-yap](https://github.com/vscosta/doxygen-yap), a
|
||||
version of doxygen adapted to Prolog that was used to generate
|
||||
these documents.
|
||||
|
@ -48,9 +48,9 @@ generate Makefiles, Ninja, Apple's XCode, VisualStudio and ANdroid
|
|||
Studio, and because it includes packaging suppport, The steps required
|
||||
to install core YAP under `cmake`:
|
||||
|
||||
##### Ensure that you have a working `C/C++` compiler in your system
|
||||
##### `C/C++` compiler
|
||||
|
||||
1. Status as of early 17
|
||||
*Status as of early 2017*
|
||||
|
||||
YAP should compile well under the [GNU-CC](https://gcc.gnu.org/)
|
||||
and the [C-LANG]https://clang.llvm.org/() families, that are
|
||||
|
@ -58,23 +58,27 @@ to install core YAP under `cmake`:
|
|||
undder Intel `icc`.
|
||||
|
||||
We do not recommend using Microoft's VC++. To the best of our
|
||||
knowledge MSC does not support threaded code, which YAP recquires
|
||||
knowledge MSC does not support threaded emulation, which YAP recquires
|
||||
for performance, You can still use the IDE, and experiment with
|
||||
the c-lang plugin.
|
||||
|
||||
YAP compiles cleanly under cross-compilers, and we have used the
|
||||
crosss-compirt [mxe](http://mxe.cc/) system with good results.
|
||||
crosss-compilation system [mxe](http://mxe.cc/) system with good results.
|
||||
|
||||
##### Ensure that you have a working `cmake` in your systen,
|
||||
##### `cmake`
|
||||
|
||||
All Linux and BSD distributions include `cmake`, so
|
||||
does [Homebrew](https://brew.sh/)
|
||||
and [MacPorts](https://www.macports.org/) for the Mac,
|
||||
and [MSYS2](http://www.msys2.org/) and [cygwin](http://www.cygwin.org/)
|
||||
for WIN32. Android Studio has native support, and there are excellenr
|
||||
plugins for the Visual Codes. The `cmake` site includes pre-compiled
|
||||
binaries. If you have an older Linux you may need to compile from
|
||||
source, available at GitHub.
|
||||
and [MSYS2](http://www.msys2.org/)
|
||||
and [cygwin](http://www.cygwin.org/) for WIN32. Android Studio has
|
||||
native support for `cmake`since 2.1, although we advise to use
|
||||
2.2. Last, there are excellent plugins for the Visual Codes. In case
|
||||
you need a recent version, consider using pre-compiled binaries at
|
||||
the [CMake site](https://www.cmake.org).
|
||||
|
||||
If you have an older Linux you may need to compile from source,
|
||||
available at GitHub.
|
||||
|
||||
##### Ensure that you have other necessary packages installed:
|
||||
|
||||
|
|
|
@ -1,5 +1,7 @@
|
|||
Attributed Variables and Co-Routining {#AttributedVariables}
|
||||
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
|
||||
|
@ -24,12 +26,12 @@ 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.
|
||||
|
||||
+ @ewd attributes
|
||||
+ @ref SICS_attributes
|
||||
+ @ref New_Style_Attribute_Declarations
|
||||
+ @ref CohYroutining
|
||||
+ @ref AttributeVariables_Builtins
|
||||
|
||||
@section attributes SICStus Style attribute declarations.
|
||||
@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:
|
||||
|
|
|
@ -14,4 +14,6 @@ with cudd binaries. This works:
|
|||
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
|
||||
|
|
|
@ -3,29 +3,13 @@ YAP Built-ins {#builtins}
|
|||
|
||||
This chapter describes the core predicates that control the execution of
|
||||
Prolog programs, provide fundamental functionality such as termm manipulation or arithmetic, and support interaction with external
|
||||
resources, Many of the predicates described here have been standardised by the ISO. The standartised subset of Proloh also known as ISO-Prolog.
|
||||
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 functors the following notation
|
||||
will be used:
|
||||
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.
|
||||
+ @ref YAPControl
|
||||
|
||||
+ @ref Arithmetic
|
||||
|
||||
+ @ref YAPChars
|
||||
|
||||
+ @ref YAP_Terms
|
||||
|
||||
+ @ref InputOutput
|
||||
|
||||
+ @ref AbsoluteFileName
|
||||
|
||||
+ @ref YAPOS
|
||||
|
||||
+ @ref Internal_Database
|
||||
|
||||
+ @ref Sets
|
||||
|
|
|
@ -1,12 +1,12 @@
|
|||
Extensions to core Prolog. {#extensions}
|
||||
=========================
|
||||
========================
|
||||
|
||||
YAP includes a number of extensions over the original Prolog
|
||||
language. Next, we discuss how to use the most important ones.
|
||||
language.
|
||||
|
||||
+ @ref Rational_Trees
|
||||
|
||||
+ @ref AttributedVariables
|
||||
+ @subpage attributes
|
||||
|
||||
+ @ref DepthLimited
|
||||
|
||||
|
@ -19,3 +19,6 @@ language. Next, we discuss how to use the most important ones.
|
|||
+ @ref YAPArrays
|
||||
|
||||
+ @ref Parallelism
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -1,11 +1,11 @@
|
|||
Loading and Oganising YAP Programs {#consult}
|
||||
Loading and Oganising YAP Programs {#load_files}
|
||||
===================================
|
||||
|
||||
Next, we present the main predicates and directives available to load
|
||||
files and to control the Prolog environment.
|
||||
|
||||
+ @subpage modules.md
|
||||
+ @subpage YAPModules
|
||||
|
||||
+ @ref YAPConsulting
|
||||
|
||||
+ @ref YAPSaving
|
||||
+ @ref QLY
|
||||
|
|
|
@ -1,7 +1,5 @@
|
|||
The YAP Module system
|
||||
======================
|
||||
|
||||
[TOC]
|
||||
The YAP Module system {#YAPModules}
|
||||
=====================
|
||||
|
||||
The YAP module system is based on the Quintus/SISCtus module
|
||||
system ˜\cite quintus . In this design, modules are named collections of predicates,
|
||||
|
|
|
@ -1,21 +1,21 @@
|
|||
YAP packages files {#packages}
|
||||
===================
|
||||
YAP packages files {packages}
|
||||
==============================
|
||||
|
||||
+ @subpage real
|
||||
|
||||
+ @ref BDDs
|
||||
+ @subpage bdds
|
||||
|
||||
+ @subpage gecode
|
||||
|
||||
+ @subpage myddas
|
||||
|
||||
+ @ref PFL/CLP(BN)
|
||||
+ @ref PFL
|
||||
|
||||
+ @ref ProbLog1
|
||||
+ @subpage ProbLog1
|
||||
|
||||
+ @ref Python
|
||||
|
||||
+ @subpage YAPRaptor
|
||||
+ @subpage raptor
|
||||
|
||||
+ @ref YAP-LBFGS
|
||||
|
||||
|
@ -26,3 +26,5 @@ Leuven packages ported from SWI-Prolog:
|
|||
+ @subpage chr
|
||||
|
||||
+ @subpage clpqr
|
||||
|
||||
|
||||
|
|
|
@ -0,0 +1,10 @@
|
|||
Programming in YAP {#YAPProgramming}
|
||||
====================
|
||||
|
||||
+ @subpage YAPSyntax
|
||||
|
||||
+ @ref YAPCompilerSettings
|
||||
|
||||
+ @ref Indexing
|
||||
|
||||
+ @ref Deb_Interaction
|
|
@ -1,5 +1,7 @@
|
|||
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
|
||||
|
|
|
@ -1,6 +1,7 @@
|
|||
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
|
||||
|
|
|
@ -1,18 +1,27 @@
|
|||
YAP 6-3.5 Manual {#mainpage}
|
||||
====================
|
||||
|
||||
This file documents the YAP Prolog System version 6.3.4, a high-performance Prolog compiler developed at LIACC, Universidade do Porto. YAP is based on David H. D. Warren's WAM (Warren Abstract Machine), with several optimizations for better performance. YAP follows the Edinburgh tradition, and is largely compatible with DEC-10 Prolog, Quintus Prolog, and originally with C-Prolog.
|
||||
<center>
|
||||
![The YAP Logo](docs/icons/yap_128x128x32.png)
|
||||
</center>
|
||||
|
||||
NOTE: this version of YAP is still experimental, documentation may be out of date.
|
||||
|
||||
## Introduction
|
||||
|
||||
This document provides User information on version 6.3.4 of
|
||||
YAP (<em>Yet Another Prolog</em>). The YAP Prolog System is a
|
||||
high-performance Prolog compiler developed at Universidade do
|
||||
Porto.
|
||||
|
||||
The manual is organised as follows:
|
||||
|
||||
|
||||
+ @subpage download
|
||||
|
||||
+ @subpage install
|
||||
|
||||
+ @subpage run
|
||||
|
||||
+ @subpage consult
|
||||
+ @subpage load_files
|
||||
|
||||
+ @subpage builtins
|
||||
|
||||
|
@ -22,15 +31,11 @@ The manual is organised as follows:
|
|||
|
||||
+ @subpage packages
|
||||
|
||||
+ @subpage swi_iso_c
|
||||
|
||||
+ @subpage YAPProgramming
|
||||
|
||||
+ @subpage fli_c_cxx
|
||||
|
||||
|
||||
|
||||
|
||||
\author Vitor Santos Costa,
|
||||
\author Luís Damas,
|
||||
\author Rogério Reis
|
||||
|
|
|
@ -18,17 +18,10 @@
|
|||
|
||||
@file YapInterface.h
|
||||
|
||||
@addtogroup ChYInterface
|
||||
@{
|
||||
|
||||
@defgroup fli_c_cx Foreign Language interface to YAP
|
||||
|
||||
@toc
|
||||
|
||||
@defgroup ChYInterface C interface to YAP
|
||||
@{
|
||||
|
||||
@ingroup fli_c_cx
|
||||
|
||||
\
|
||||
@brief Core interface to YAP.
|
||||
|
||||
@toc
|
||||
|
|
|
@ -13,7 +13,11 @@
|
|||
* comments: c_interface header file for YAP *
|
||||
* *
|
||||
*************************************************************************/
|
||||
|
||||
/**
|
||||
* @file c_interface.h
|
||||
*
|
||||
* @addtogroup ChYInterface
|
||||
*/
|
||||
#if !defined(_c_interface_h) && !defined(_YAP_NOT_INSTALLED_)
|
||||
|
||||
#define _c_interface_h 1
|
||||
|
|
|
@ -10,7 +10,7 @@
|
|||
/**
|
||||
*
|
||||
|
||||
@defgroup arg Term Argument Manipulation.
|
||||
@defgroup args Term Argument Manipulation.
|
||||
|
||||
@ingroup @library
|
||||
|
||||
|
|
|
@ -18,10 +18,13 @@
|
|||
:- module(attributes, [op(1150, fx, attribute)]).
|
||||
|
||||
/**
|
||||
@addtogroup attributes
|
||||
|
||||
|
||||
%% @{
|
||||
*
|
||||
* @defgroup sicsatts SICStus style attribute declarations
|
||||
*
|
||||
* @ingroup attributes
|
||||
*
|
||||
* @{
|
||||
*
|
||||
|
||||
SICStus style attribute declarations are activated through loading the
|
||||
library <tt>atts</tt>. The command
|
||||
|
|
|
@ -2,12 +2,16 @@
|
|||
% SWI emulation.
|
||||
% written in an on-demand basis.
|
||||
|
||||
%% @defgroup swi Compatibility with SWI-Prolog and Other Prolog systems
|
||||
%% @defgroup SWI Compatibility with SWI-Prolog and Other Prolog systems
|
||||
%% @{
|
||||
%% @ingroup YAPProgramming
|
||||
|
||||
/**
|
||||
|
||||
@defgroup System SWI Dialect Support
|
||||
@ingroup SWI
|
||||
|
||||
@{
|
||||
|
||||
This library provides a number of SWI-Prolog builtins that are not by
|
||||
default in YAP. This support is loaded with the
|
||||
|
@ -17,8 +21,6 @@ expects_dialect(swi)
|
|||
|
||||
command.
|
||||
|
||||
@{
|
||||
|
||||
*/
|
||||
|
||||
/** @pred time_file(+ _File_,- _Time_)
|
||||
|
@ -317,5 +319,7 @@ required_predicate(Na/Ar, M) :-
|
|||
).
|
||||
|
||||
/**
|
||||
@}
|
||||
|
||||
@}
|
||||
*/
|
||||
|
|
|
@ -38,7 +38,7 @@
|
|||
]).
|
||||
|
||||
/**
|
||||
* @defsgroup readutil
|
||||
* @defgroup readutil
|
||||
* @ingroup library
|
||||
*
|
||||
* Read full lines and a full file in a single call.
|
||||
|
|
|
@ -16,7 +16,7 @@
|
|||
|
||||
/**
|
||||
* @defgroup varnumbers Variabilize term.
|
||||
* @ingroup ellllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll
|
||||
* @ingroup library
|
||||
*
|
||||
*/
|
||||
|
||||
|
|
|
@ -29,7 +29,6 @@ static char SccsId[] = "%W% %G%";
|
|||
|
||||
///{@
|
||||
|
||||
/// @addtogroup CharProps
|
||||
/**
|
||||
* @defgroup CharIO Character-Based Input/Output
|
||||
* @ingroup InputOutput
|
||||
|
|
|
@ -1386,7 +1386,6 @@ digit_weight( 0x1D7D7, 9).
|
|||
digit_weight( 0x1D7E1, 9).
|
||||
digit_weight( 0x1D7EB, 9).
|
||||
digit_weight( 0x1D7F5, 9).
|
||||
x
|
||||
digit_weight( 0x1D7FF, 9).
|
||||
digit_weight( 0x1E8CF, 9).
|
||||
digit_weight( 0x1F10A, 9).
|
||||
|
|
|
@ -18,8 +18,8 @@
|
|||
|
||||
/**
|
||||
* @file fmemopen.c
|
||||
* @defgroup Memory Streams.
|
||||
* @in.
|
||||
* @defgroup MemoryStreams Memory Streams
|
||||
* @ingroup InputOutput
|
||||
* @return Description of returned value.
|
||||
*/
|
||||
#ifdef __APPLE__
|
||||
|
|
|
@ -22,7 +22,7 @@
|
|||
]).
|
||||
|
||||
/** @defgroup PFL The PrologFactor Language
|
||||
@ingroup YAPPackagaes
|
||||
@ingroup packages
|
||||
|
||||
section{Introduction}
|
||||
The Prolog Factor Language (PFL) is a language that extends Prolog for providing a syntax to describe first-order probabilistic graphical models. These models can be either directed (bayesian networks) or undirected (markov networks). This language replaces the old one known as CLP(BN).
|
||||
|
|
|
@ -1,7 +1,8 @@
|
|||
/** @defgroup BDDs Binary Decision Diagrams and Friends
|
||||
@ingroup packages
|
||||
@defgroup BDDsPL Binary Decision Diagrams and Friends
|
||||
@ingroup BDDs
|
||||
@{
|
||||
|
||||
|
||||
This library provides an interface to the BDD package CUDD. It requires
|
||||
CUDD compiled as a dynamic library. In Linux this is available out of
|
||||
box in Fedora, but can easily be ported to other Linux
|
||||
|
|
|
@ -28,7 +28,8 @@
|
|||
invalidate any other reasons why the executable file might be covered by
|
||||
the GNU General Public License.
|
||||
*/
|
||||
%% @addtogroup CHR_in_YAP_Programs
|
||||
%% @addtogroup CHR_in_YAP_Programs CHR Programs
|
||||
%% @ingroup CHR
|
||||
%
|
||||
% CHR controlling the compiler
|
||||
%
|
||||
|
|
|
@ -29,7 +29,8 @@
|
|||
the GNU General Public License.
|
||||
*/
|
||||
|
||||
%% @addtogroup CHR_Debugging
|
||||
%% @addtogroup CHR_Debugging Debugging
|
||||
%% @ingroup CHR
|
||||
%
|
||||
% CHR debugger
|
||||
%
|
||||
|
|
|
@ -68,7 +68,8 @@
|
|||
%% * Added initialization directives for saved-states
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
%% @addtogroup CHR_Rule_Types
|
||||
%% @addtogroup CHR_Rule_Types Rule Types
|
||||
%% @ingroup CHR
|
||||
%
|
||||
% CHR controlling the compiler
|
||||
%
|
||||
|
|
|
@ -30,7 +30,8 @@
|
|||
*/
|
||||
|
||||
%% SWI begin
|
||||
%% @addtogroup CHR
|
||||
%% @addtogroup CHR chr
|
||||
%% @ingroup packages
|
||||
%
|
||||
% SWI interface.
|
||||
%
|
||||
|
|
|
@ -38,9 +38,14 @@
|
|||
the GNU General Public License.
|
||||
*/
|
||||
|
||||
/** @addtogroup clpqr CLP(QR)
|
||||
@ingroup packages
|
||||
@{
|
||||
*/
|
||||
|
||||
/** @defgroup clpr_implementation CLP(QR) Predicates
|
||||
@ingroup clpqr
|
||||
|
||||
@{
|
||||
*/
|
||||
|
||||
/** @pred bb_inf(+ _Ints_,+ _Expression_,- _Inf_)
|
||||
|
@ -205,3 +210,7 @@ memberchk_eq(X,[Y|Ys]) :-
|
|||
-> true
|
||||
; memberchk_eq(X,Ys)
|
||||
).
|
||||
|
||||
%% @}
|
||||
|
||||
%% @}
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
%% -*- prolog -*-
|
||||
pgec%% -*- prolog -*-
|
||||
%%=============================================================================
|
||||
%% Copyright (C) 2011 by Denys Duchier
|
||||
%%
|
||||
|
@ -31,7 +31,7 @@ Duchier, with recent work by Vítor Santos Costa to port it to version 4
|
|||
of gecode and to have an higher level interface,
|
||||
|
||||
|
||||
@defgroup The_Gecode_Interface The Gecode Interface
|
||||
@addtogroup The_Gecode_Interface The Gecode Interface
|
||||
@ingroup Gecode
|
||||
@{
|
||||
|
||||
|
|
|
@ -0,0 +1,15 @@
|
|||
|
||||
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.
|
||||
|
||||
.
|
|
@ -1,14 +1,20 @@
|
|||
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
|
||||
ee
|
||||
@ingroup #myddas
|
||||
|
||||
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
|
||||
or the ODBC development libraries. At least one of the this development
|
||||
|
@ -40,6 +46,7 @@
|
|||
we were using Datalog.
|
||||
|
||||
@defgroup MYDDAS_Architecture MYDDAS Architecture
|
||||
@ingroup myddas
|
||||
|
||||
The system includes four main blocks that are put together through the
|
||||
MYDDAS interface: the Yap Prolog compiler, the MySQL database system, an
|
||||
|
@ -64,33 +71,32 @@
|
|||
Prolog cut operator, which has exactly the same behaviour from
|
||||
predicates defined in the Prolog program source code, or from predicates
|
||||
defined in database as relations.
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Name = 'John Doe',
|
||||
Number = 123456789 ?
|
||||
yes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Backtracking can then be used to retrieve the next row
|
||||
of the relation phonebook. Records with particular field values may be
|
||||
selected in the same way as in Prolog. (In particular, no mode
|
||||
specification for database predicates is required). For instance:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- phonebook(Letter,'John Doe',Letter).
|
||||
Letter = 'D',
|
||||
Number = 123456789 ?
|
||||
yes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
generates the query
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
SELECT A.Letter , 'John Doe' , A.Number
|
||||
FROM 'phonebook' A
|
||||
WHERE A.Name = 'John Doe';
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@defgroup View_Level_Interface View Level Interface
|
||||
@ingroup myddas
|
||||
|
||||
@pred db view(+,+,+).
|
||||
|
||||
|
@ -101,18 +107,18 @@
|
|||
|
||||
If we import a database relation, such as an edge relation representing the edges of a directed graph, through
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_import('Edge',edge).
|
||||
yes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
sqliand we then write a query to retrieve all the direct cycles in the
|
||||
graph, such as
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- edge(A,B), edge(B,A).
|
||||
A = 10,
|
||||
B = 20 ?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
this is clearly inefficient [3], because of relation-level
|
||||
access. Relation-level access means that a separate SQL query will be
|
||||
generated for every goal in the body of the clause. For the second
|
||||
|
@ -129,10 +135,10 @@
|
|||
predicates. One can use the view level interface through the predicates
|
||||
db_view/3 and `db_view/2`:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_view(Conn,PredName(Arg_1,...,Arg_n),DbGoal).
|
||||
?- db_view(PredName(Arg_1,...,Arg_n),DbGoal).
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
All arguments are standard Prolog terms. _Arg1_ through _Argn_
|
||||
define the attributes to be retrieved from the database, while
|
||||
_DbGoal_ defines the selection restrictions and join
|
||||
|
@ -142,48 +148,48 @@
|
|||
an example of a view definition for the direct cycles discussed
|
||||
above. Assuming the declaration:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_import('Edge',edge).
|
||||
yes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
we
|
||||
write:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_view(direct_cycle(A,B),(edge(A,B), edge(B,A))).
|
||||
yes
|
||||
?- direct_cycle(A,B)).
|
||||
A = 10,
|
||||
B = 20 ?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
This call generates the SQL
|
||||
statement:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
SELECT A.attr1 , A.attr2
|
||||
FROM Edge A , Edge B
|
||||
WHERE B.attr1 = A.attr2 AND B.attr2 = A.attr1;
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Backtracking, as in relational level interface, can be used to retrieve the next row of the view.
|
||||
The view interface also supports aggregate function predicates such as
|
||||
`sum`, `avg`, `count`, `min` and `max`. For
|
||||
instance:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_view(count(X),(X is count(B, B^edge(10,B)))).
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
generates the query :
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
SELECT COUNT(A.attr2)
|
||||
FROM Edge A WHERE A.attr1 = 10;
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
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
|
||||
|
||||
|
||||
@pred db_sql(+,+,?).
|
||||
|
@ -196,22 +202,22 @@
|
|||
|
||||
It is also possible to explicitly send a SQL query to the database server using
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_sql(Conn,SQL,List).
|
||||
?- db_sql(SQL,List).
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
where _SQL_ is an arbitrary SQL expression, and _List_ is a list
|
||||
holding the first tuple of result set returned by the server. The result
|
||||
set can also be navigated through backtracking.
|
||||
|
||||
Example:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_sql('SELECT * FROM phonebook',LA).
|
||||
LA = ['D','John Doe',123456789] ?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@defgroup Insertion_of_Rows Insertion of Rows
|
||||
@ingroup myddas
|
||||
@ingroup MYDDAS
|
||||
|
||||
@pred db_assert(+,+).
|
||||
|
@ -224,36 +230,36 @@
|
|||
`db_import/2` or db_import/3, you can insert to that table
|
||||
by using db_assert/2 predicate any given fact.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_assert(Conn,Fact).
|
||||
?- db_assert(Fact).
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
The second argument must be declared with all of its arguments bound to
|
||||
constants. For example assuming `helloWorld` is imported through
|
||||
`db_import/2`:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_import('Hello World',helloWorld).
|
||||
yes
|
||||
?- db_assert(helloWorld('A' ,'Ana',31)).
|
||||
yes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
This, would generate the following query
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
INSERT INTO helloWorld
|
||||
VALUES ('A','Ana',3)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
which would insert into the helloWorld, the following row:
|
||||
`A,Ana,31`. If we want to insert `NULL` values into the
|
||||
relation, we call db_assert/2 with a uninstantiated variable in
|
||||
the data base imported predicate. For example, the following query on
|
||||
the YAP-prolog system:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_assert(helloWorld('A',NULL,31)).
|
||||
yes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Would insert the row: `A,null value,31` into the relation
|
||||
`Hello World`, assuming that the second row allows null values.
|
||||
|
@ -268,22 +274,23 @@
|
|||
This predicate would create a new database predicate, which will insert
|
||||
any given tuple into the database.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_insert(Conn,RelationName,PredName).
|
||||
?- db_insert(RelationName,PredName).
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
This would create a new predicate with name _PredName_, that will
|
||||
insert tuples into the relation _RelationName_. is the connection
|
||||
identifier. For example, if we wanted to insert the new tuple
|
||||
`('A',null,31)` into the relation `Hello World`, we do:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_insert('Hello World',helloWorldInsert).
|
||||
yes
|
||||
?- helloWorldInsert('A',NULL,31).
|
||||
yes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@defgroup Types_of_Attributes Types of AttributesL
|
||||
@ingroup myddas
|
||||
|
||||
|
||||
@pred db_get_attributes_types(+,+,?).
|
||||
|
@ -297,25 +304,25 @@
|
|||
|
||||
The prototype for this predicate is the following:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_get_attributes_types(Conn,RelationName,ListOfFields).
|
||||
?- db_get_attributes_types(RelationName,ListOfFields).
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
You can use the
|
||||
predicate `db_get_attributes types/2` or db_get_attributes_types/3, to
|
||||
know what are the names and attributes types of the fields of a given
|
||||
relation. For example:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_get_attributes_types(myddas,'Hello World',LA).
|
||||
LA = ['Number',integer,'Name',string,'Letter',string] ?
|
||||
yes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
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
|
||||
|
||||
|
||||
@pred db_number_of_fields(+,?).
|
||||
|
@ -326,23 +333,24 @@
|
|||
The prototype for this
|
||||
predicate is the following:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_number_of_fields(Conn,RelationName,Arity).
|
||||
?- db_number_of_fields(RelationName,Arity).
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
You can use the predicate db_number_of_fields/2 or
|
||||
`db_number_of_fields/3` to know what is the arity of a given
|
||||
relation. Example:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_number_of_fields(myddas,'Hello World',Arity).
|
||||
Arity = 3 ?
|
||||
yes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
where `Hello World` is the name of the
|
||||
relation and `myddas` is the connection identifier.
|
||||
|
||||
@defgroup Describing_a_Relation Describing a Relation
|
||||
@ingroup #myddas
|
||||
|
||||
@pred db_datalog_describe(+,+).
|
||||
@pred db_datalog_describe(+).
|
||||
|
@ -353,7 +361,7 @@
|
|||
value. It simply prints to the screen the result of the MySQL describe
|
||||
command, the same way as `DESCRIBE` in the MySQL prompt would.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_datalog_describe(myddas,'Hello World').
|
||||
+----------+----------+------+-----+---------+-------+
|
||||
| Field | Type | Null | Key | Default | Extra |
|
||||
|
@ -363,7 +371,7 @@
|
|||
+ Letter | char(1) | YES | | NULL | |
|
||||
+----------+----------+------+-----+---------+-------+
|
||||
yes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@pred db_describe(+,+).
|
||||
|
||||
|
@ -376,15 +384,15 @@
|
|||
difference. The results are returned by backtracking. For example, the
|
||||
last query:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_describe(myddas,'Hello World',Term).
|
||||
Term = tableInfo('Number',int(11),'YES','',null(0),'') ? ;
|
||||
Term = tableInfo('Name',char(10),'YES','',null(1),'' ? ;
|
||||
Term = tableInfo('Letter',char(1),'YES','',null(2),'') ? ;
|
||||
no
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@defgroup Enumerating_Relations Enumeration Relations Describing_a_Relation Describing a Relation
|
||||
@ingroup #myddas
|
||||
|
||||
|
||||
/@pred db_datalog_show_tables(+).
|
||||
|
@ -396,7 +404,7 @@
|
|||
it does not returns any value, but instead prints to the screen the result of the
|
||||
`SHOW TABLES` command, the same way as it would be in the MySQL prompt.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_datalog_show_tables(myddas).
|
||||
+-----------------+
|
||||
| Tables_in_guest |
|
||||
|
@ -404,7 +412,7 @@
|
|||
| Hello World |
|
||||
+-----------------+
|
||||
yes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@pred db_show_tables(+, ?).
|
||||
|
||||
|
||||
|
@ -418,12 +426,15 @@
|
|||
`db_show_tables/1` predicate but with one major difference. The
|
||||
results are returned by backtracking. For example, given the last query:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_show_tables(myddas,Table).
|
||||
Table = table('Hello World') ? ;
|
||||
no
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
@defgroup The_MYDDAS_MySQL_Top_Level The MYDDAS MySQL Top Level
|
||||
@ingroup #myddas
|
||||
|
||||
@pred db_top_level(+,+,+,+,+).
|
||||
@pred db_top_level(+,+,+,+).
|
||||
|
@ -437,27 +448,27 @@
|
|||
different from the standard mysql client. We can use this
|
||||
mode, by invoking the db top level/5. as one of the following:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_top_level(mysql,Connection,Host/Database,User,Password).
|
||||
?- db_top_level(mysql,Connection,Host/Database/Port,User,Password).
|
||||
?- db_top_level(mysql,Connection,Host/Database/UnixSocket,User,Password).
|
||||
?- db_top_level(mysql,Connection,Host/Database/Port/UnixSocket,User,Password).
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Usage is similar as the one described for the db_open/5 predicate
|
||||
discussed above. If the login is successful, automatically the prompt of
|
||||
the mysql client will be used. For example:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_top_level(mysql,con1,localhost/guest_db,guest,'').
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
opens a
|
||||
connection identified by the `con1` atom, to an instance of a MySQL server
|
||||
running on host `localhost`, using database guest `db` and user `guest` with
|
||||
empty password. After this is possible to use MYDDAS as the mysql
|
||||
client.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_top_level(mysql,con1,localhost/guest_db,guest,'').
|
||||
Reading table information for completion of table and column names
|
||||
You can turn off this feature to get a quicker startup with -A
|
||||
|
@ -472,8 +483,10 @@
|
|||
Bye
|
||||
yes
|
||||
?-
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@defgroup Other_MYDDAS_Properties Other MYDDAS Properties
|
||||
@ingroup #myddas
|
||||
|
||||
@pred db_verbose(+).
|
||||
|
||||
|
@ -483,11 +496,11 @@
|
|||
`QUERY`. If we want to see that query, we must to this at a given
|
||||
point in our session on YAP.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_verbose(1).
|
||||
yes
|
||||
?-
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
If we want to
|
||||
disable this feature, we must call the `db_verbose/1` predicate with the value 0.
|
||||
|
||||
|
@ -504,51 +517,51 @@
|
|||
by default on the `user` module. If we want to change this value, we can
|
||||
use the db_module/1 predicate to do so.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_module(lists).
|
||||
yes
|
||||
?-
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
By executing this predicate, all of the predicates asserted by the
|
||||
predicates enumerated earlier will created in the lists module.
|
||||
If we want to put back the value on default, we can manually put the
|
||||
value user. Example:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_module(user).
|
||||
yes
|
||||
?-
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
We can also see in what module the predicates are being asserted by doing:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_module(X).
|
||||
X=user
|
||||
yes
|
||||
?-
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@pred db_my_result_set(?).
|
||||
|
||||
The MySQL C API permits two modes for transferring the data generated by
|
||||
a query to the client, in our case YAP. The first mode, and the default
|
||||
mode used by the MYDDAS-MySQL, is to store the result. This mode copies all the
|
||||
mod-MySQL, is to store the result. This mode copies all the
|
||||
information generated to the client side.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_my_result_set(X).
|
||||
X=store_result
|
||||
yes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The other mode that we can use is use result. This one uses the result
|
||||
set created directly from the server. If we want to use this mode, he
|
||||
simply do
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?- db_my_result_set(use_result).
|
||||
yes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
After this command, all
|
||||
of the database predicates will use use result by default. We can change
|
||||
this by doing again `db_my_result_set(store_result)`.
|
||||
|
@ -567,8 +580,10 @@
|
|||
not to ignore the INSERT statement warnings and instead of taking
|
||||
action, report an error, we could use the following SQL mode.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
?-db_my_sql_mode(traditional). yes
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
You can see the available SQL Modes at the MySQL homepage at
|
||||
<http://www.mysql.org>.
|
||||
|
||||
@}
|
|
@ -1,4 +1,4 @@
|
|||
WWW Reader/Writers for YAP. {#YAPRaptor}
|
||||
WWW Reader/Writers for YAP. {#raptor}
|
||||
=========================
|
||||
|
||||
This provides YAP a rdf reader using
|
|
@ -6,7 +6,7 @@ The R Prolog Progrmming Interface {#real}
|
|||
@author Vitor Santos Costa
|
||||
@version 1:0:4, 2013/12/25, sinter_class
|
||||
@license Perl Artistic License
|
||||
@defgroup libReal An interface to the R statistical software.
|
||||
|
||||
@ingroup packages
|
||||
|
||||
|
|
@ -61,6 +61,7 @@ typedef double lbfgsfloatval_t;
|
|||
|
||||
/**
|
||||
* \addtogroup liblbfgs_api libLBFGS API
|
||||
* @ingroup YAP-LBFGS
|
||||
* @{
|
||||
*
|
||||
* The libLBFGS API.
|
||||
|
|
|
@ -1,4 +1,4 @@
|
|||
#include <string.h>
|
||||
o#include <string.h>
|
||||
#include "YapInterface.h"
|
||||
#include <lbfgs.h>
|
||||
#include <stdio.h>
|
||||
|
|
|
@ -23,7 +23,7 @@
|
|||
:- use_system_module( '$_errors', ['$do_error'/2]).
|
||||
|
||||
|
||||
/?**
|
||||
/**
|
||||
* @addtogroup Predicates_on_Atoms
|
||||
*
|
||||
*/
|
||||
|
|
|
@ -18,9 +18,11 @@
|
|||
/**
|
||||
@file attributes.yap
|
||||
|
||||
@{
|
||||
|
||||
@addtogroup New_Style_Attribute_Declarations
|
||||
@defgroup New_Style_Attribute_Declarations SWI Compatible attributes
|
||||
@{
|
||||
@ingroup attributes
|
||||
|
||||
*/
|
||||
|
||||
:- module('$attributes', [
|
||||
|
@ -489,7 +491,6 @@ typically this will involve expressing all constraints in terms of
|
|||
_QueryVars_ and considering all remaining variables as existentially
|
||||
quantified.
|
||||
|
||||
|
||||
Projection interacts with attribute_goal/2 at the Prolog top
|
||||
level. When the query succeeds, the system first calls
|
||||
project_attributes/2. The system then calls
|
||||
|
@ -498,8 +499,6 @@ constraints. Typically, attribute_goal/2 will convert from the
|
|||
original constraints into a set of new constraints on the projection,
|
||||
and these constraints are the ones that will have an
|
||||
attribute_goal/2 handler.
|
||||
|
||||
|
||||
*/
|
||||
project_attributes(AllVs, G) :-
|
||||
attributes:modules_with_attributes(LMods),
|
||||
|
@ -523,6 +522,6 @@ project_module([Mod|LMods], LIV, LAV) :-
|
|||
project_module([_|LMods], LIV, LAV) :-
|
||||
project_module(LMods,LIV,LAV).
|
||||
|
||||
/**
|
||||
@}
|
||||
*/
|
||||
%% @}
|
||||
|
||||
|
||||
|
|
|
@ -74,12 +74,13 @@
|
|||
|
||||
:- use_system_module( '$_preds', ['$current_predicate'/4]).
|
||||
|
||||
%% @{
|
||||
|
||||
/**
|
||||
|
||||
@defgroup YAPConsulting Loading files into YAP
|
||||
@ingroup consult
|
||||
|
||||
@{
|
||||
|
||||
We present the main predicates and directives available to load
|
||||
files and to set-up the Prolog environment. We discuss
|
||||
|
||||
|
@ -87,12 +88,10 @@ files and to set-up the Prolog environment. We discuss
|
|||
|
||||
+ @ref YAPCompilerSettings
|
||||
|
||||
@{
|
||||
|
||||
@defgroup YAPReadFiles The Predicates that Read Source Files
|
||||
@ingroup YAPConsulting
|
||||
|
||||
|
||||
@{
|
||||
*/
|
||||
|
||||
/**
|
||||
|
|
|
@ -24,7 +24,7 @@
|
|||
* @addtogroup extensions Extensions to Core Prolog
|
||||
*
|
||||
* @{
|
||||
* @ addtogroup AttributeVariables Attributed Variables and Co-Routining
|
||||
* @ addtogroup attributes Attributed Variables and Co-Routining
|
||||
* @{
|
||||
* @brief Support for co-routining
|
||||
*
|
||||
|
@ -43,7 +43,6 @@
|
|||
|
||||
:- use_system_module( '$_boot', ['$$compile'/4]).
|
||||
|
||||
:- use_system_module( '$_errors', ['$do_error'/2]).
|
||||
|
||||
:- use_system_module( attributes, [get_module_atts/2,
|
||||
put_module_atts/2]).
|
||||
|
@ -52,7 +51,7 @@
|
|||
%%@{
|
||||
|
||||
%% @aaddtogroup CohYroutining
|
||||
%% @ingroup AttributedVariables
|
||||
%% @ingroup attributes
|
||||
|
||||
/** @pred attr_unify_hook(+ _AttValue_,+ _VarValue_)
|
||||
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
//!@{
|
||||
%%% @{
|
||||
|
||||
//!@ingroup YAPModules
|
||||
}/*************************************************************************
|
||||
%%% @addtogroup YAPModules
|
||||
/*************************************************************************
|
||||
* *
|
||||
* YAP Prolog *
|
||||
* *
|
||||
|
@ -176,4 +176,4 @@ clean_up :-
|
|||
|
||||
clean_up.
|
||||
|
||||
//!@}
|
||||
%% @}
|
||||
|
|
10
pl/flags.yap
10
pl/flags.yap
|
@ -14,6 +14,16 @@
|
|||
* comments: controlling YAP *
|
||||
* *
|
||||
*************************************************************************/
|
||||
/**
|
||||
* @file flagd.ysp
|
||||
*
|
||||
* @defgroup Flags Yap Flags
|
||||
*n@{}
|
||||
* @ingroup builtins
|
||||
* @}@[ ]
|
||||
*/
|
||||
|
||||
|
||||
|
||||
:- system_module( '$_flags', [create_prolog_flag/3,
|
||||
current_prolog_flag/2,
|
||||
|
|
|
@ -385,4 +385,9 @@ clause_to_indicator(T, M:Name/Arity) :- ,
|
|||
|
||||
/**
|
||||
@}
|
||||
|
||||
@defgroup packages YAP Packages
|
||||
|
||||
|
||||
|
||||
*/
|
||||
|
|
29
pl/qly.yap
29
pl/qly.yap
|
@ -18,21 +18,8 @@
|
|||
%% @file qly.yap
|
||||
|
||||
/**
|
||||
|
||||
@defgroup YAPSaving Saving and Loading Prolog States
|
||||
@ingroup consult
|
||||
|
||||
YAP can save and read images of its current state to files, known as
|
||||
saved states. It is possible to save the entire state or just a module
|
||||
or a file. Notice that saved states in YAP depend on the architecture
|
||||
where they were made, and may also depend on the version of YAP being
|
||||
saved.
|
||||
|
||||
YAP always tries to find saved states from the current directory
|
||||
first. If it cannot it will use the environment variable [YAPLIBDIR](@ref YAPLIBDIR), if
|
||||
defined, or search the default library directory.
|
||||
|
||||
@{
|
||||
@defgroup QLY Creating and Using a saved state
|
||||
@ingroup YAPConsulting
|
||||
*/
|
||||
|
||||
:- system_module( '$_qly', [qload_module/1,
|
||||
|
@ -63,6 +50,18 @@ defined, or search the default library directory.
|
|||
:- use_system_module( '$_yio', ['$extend_file_search_path'/1]).
|
||||
|
||||
|
||||
YAP can save and read images of its current state to files, known as
|
||||
saved states. It is possible to save the entire state or just a module
|
||||
or a file. Notice that saved states in YAP depend on the architecture
|
||||
where they were made, and may also depend on the version of YAP being
|
||||
saved.
|
||||
|
||||
YAP always tries to find saved states from the current directory
|
||||
first. If it cannot it will use the environment variable [YAPLIBDIR](@ref YAPLIBDIR), if
|
||||
defined, or search the default library directory.
|
||||
|
||||
*/
|
||||
|
||||
/** @pred save_program(+ _F_)
|
||||
Saves the current state of the data-base in file _F_ .
|
||||
|
||||
|
|
|
@ -1,24 +0,0 @@
|
|||
/**
|
||||
@defgroup clib swi
|
||||
@ingroup swi
|
||||
|
||||
The clib package is a series of libraries developed by Jan Wielmaker
|
||||
and the SWI-Prolog community for extended Operating System support.
|
||||
Please consult clib.doc for the complete documentation.
|
||||
|
||||
*/
|
||||
|
||||
/**
|
||||
|
||||
@defgroup http The SWI http packages
|
||||
@ingroup swi
|
||||
|
||||
The HTTP package is a series of libraries developed by Jan Wielmaker
|
||||
and the SWI-Prolog community for accessing and serving data on the
|
||||
web. It supports lower-level transport protocols, but also
|
||||
data-representation primitives, and more.
|
||||
|
||||
The port to YAP focused on the client-side support. The server
|
||||
package has not been as widely tested.
|
||||
|
||||
*/
|
Reference in New Issue