@@ -160,8 +182,6 @@ pdfauthor={I am the Author} % author
\author{J. Travnicek}
\title{The algorithms library toolkit}
\usepackage{lipsum}% Just to put in some text
\begin{document}
\frontmatter
...
...
@@ -169,7 +189,7 @@ pdfauthor={I am the Author} % author
\maketitle
\begin{abstract}
\lipsum[1-2]
The algorithms library toolkit is a collection of datatypes and algorithms. The datatypes cover various kinds of automata, grammars, regexps, trees, tree regular expressions, strings, and some indexing structures. Algorithms cover manipulation and conversion algorithms of automata, grammar, regexp, tree regular expressions, some basic string and tree index creation algorithms, and tree and string matching algorithms. The implementation is in c++14 standard and heavily using templates. The toolkit comes with a command line interface and with still evolving graphical interface.
\end{abstract}
\clearpage
...
...
@@ -194,6 +214,7 @@ The command line interface binary can at start react to changes of algorithms pr
A limited graphical interface allowing to desing complex algorithm is also provided. The limitation is in the number of available algorithms, which is a static subset of all algorithms. The graphical interface is planed to be extended to support all registered algorithm similarly to the command line interface.
The toolkit is extensible and as long as the added datatype or algorithm connects itself to already exitent code via cast or conversion algorithm, the extension can benefit from features already implemented.
\mainmatter
\chapter{Structure of the code}
...
...
@@ -212,7 +233,13 @@ Compilation may be tuned with some parameters in configuration file. Library nam
\section{Existing modules}
The algorithm library toolkit consists of these modules: alib2std, alib2measure, alib2abstraction, alib2common, alib2xml, alib2data, alib2aux, alib2str, alib2raw, alib2algo, and alib2cli. Additionaly there are some more modules available mainly for testing purposes: alib2data\_experimental, alib2algo\_experimental, alib2elgo, alib2graph\_data, alib2graph\_algo, and alib2dummy.
The algorithm library toolkit consists of three types of modules: core, feature, experimental.
The core modules include: alib2std (c++ standard library extensions), alib2measure (support for measurements), alib2abstraction (storage of registered datatypes and algorithms, alib2common (base datatypes), alib2xml (xml export and import of basic datatypes), and alib2cli (command line interface implementation).
The feature modules include: alib2data (automata, grammar, regexps, and other datatypes), alib2aux (helper algorithms), alib2str (parsing and composing a string representation of some datatypes), alib2raw (parsing and composing of raw representation of some datatypes), alib2algo (most of the algorithms).
The experimental modules available mainly for testing purposes: alib2data\_experimental (experimental datatypes), alib2algo\_experimental (experimental algorithms), alib2elgo (more efficient implementation of some algorithms), alib2graph\_data (graph datatypes), alib2graph\_algo (graph algorithms), and alib2dummy (playground library).
\subsection{Standard library extensiton}
The module alib2std provides extensions to the c++ standard library. The extensition are placed in namespace \emph{ext}, not to colide with the same classes, functions ... in namespace \emph{std} and also because the standard disallowes placing anything new into the std namespace exept specilisations of templated types.
...
...
@@ -280,10 +307,12 @@ Many data structures are defined as a n-tuple where the components are of differ
\subsection{Component as a base of datastructure}
Using components requires to derive your datatype from a templated class \emph{code::Components}. The \emph{code::Components} class uses the \emph{Curiously recurring template pattern} in its first template parameter. Next parameters come three at a time. The first of the triplet is defining the internal datatype of the component, the second is the component behavior scheme, and the third is a name (or names) of the component.
To compose datatype using components requires to derive your datatype from a templated class \emph{code::Components}. The \emph{code::Components} class uses the \emph{Curiously recurring template pattern} in its first template parameter. Next parameters come three at a time. The first of the triplet is defining the internal datatype of the component, the second is the component behavior scheme, and the third is a name (or names) of the component.
\begin{lstlisting}
template < class SymbolType, class StateType >
class DFA final : public AutomatonBase, public core::Components < DFA < SymbolType, StateType >, ext::set < SymbolType >, component::Set, InputAlphabet, ext::set < StateType >, component::Set, std::tuple < States, FinalStates >, StateType, component::Value, InitialState >
class DFA final : public AutomatonBase, public core::Components < DFA < SymbolType, StateType >, ext::set < SymbolType >, component::Set, InputAlphabet, ext::set < StateType >, component::Set, std::tuple < States, FinalStates >, StateType, component::Value, InitialState >;
\end{lstlisting}
In this example the deterministic finite automaton is constructed from set of symbols represented by InputAlphabet component, two sets of states represented by States and FinalStates components, and a state represented by InitialState component.
...
...
@@ -303,6 +332,7 @@ To maintain consistency of datatypes constructed from components, some constrain
The \emph{component::Value} behavior scheme requires existence of available and valid static methods inside the \emph{ElementContraint} class. The method available represents check that the value to be set is available in other related components. The method valid represents additional check for validity of the setted object, if needed the method is supposed to throw an exception.
\begin{lstlisting}
template<class SymbolType, class StateType >
class ElementConstraint< automaton::DFA<SymbolType, StateType>, StateType, automaton::InitialState > {
public:
...
...
@@ -314,9 +344,11 @@ public:
}
};
\end{lstlisting}
The \emph{component::Set} behavior scheme requires existence of used, available, and valid static methods inside the \emph{SetContraint} class. The methods available and valid are the same as in case of the \emph{component::Value} behaviour sheme. The additional method used is representing check whether removed object from the set component is used in other related components.
\begin{lstlisting}
template<class SymbolType, class StateType >
class SetConstraint< automaton::DFA<SymbolType, StateType>, StateType, automaton::FinalStates > {
public:
...
...
@@ -332,9 +364,7 @@ public:
}
};
\section{Normalisation}
\label{section:normalisation}
\end{lstlisting}
\section{Abstraction}
...
...
@@ -363,32 +393,44 @@ The registration of algorithms is performed via \emph{registration::AbstractRegi
The function pointer must exactly match the requirements set up by ReturnType and ParameterTypes.
Already registered algorithm, cast, printer of datatype can be re-registered as an algorithm. Such a registration is available via \emph{registration::WrapperRegister} class. The class is templated with types Algorithm and ParameterTypes with the same meaning as in case of AbstractRegister. The class constructor accepts a function pointer to a delegate function capable of looking up the actual registered algorthm, cast, ... Also paramter names can be specified as well.
Last option is register a method. The class allowing this kind of registration is \emph{registration::MethodRegister}. It is parametrized again with types Algorithm, ReturnType, additionally ObjectType, and again ParameterTypes. The ObjectType is a decayed type of object on which to call the registered method. Constructor of the method registration class accepts pointer to method, string representing the method name, and optionaly names of parameters.
auto fooBar = registration::MethodRegister < Foo, int, Foo, int > ( \& Foo::bar, "bar" );
\begin{lstlisting}
auto fooBar = registration::MethodRegister < Foo, int, Foo, int > ( & Foo::bar, "bar" );
\end{lstlisting}
The registration::AbstractRegister and registration::MethodRegister also register the exact return type for a normalization automatically.
\subsubsection{Registration of algorithms via function call}
The basic registration is of a callback to the algorithm. That is equivalent to use of registration::AbstractRegister class. The call is to \emph{abstraction::AlgorithmRegistry::registerAlgorithm} which is parametrized with following types: Algorithm, ReturnType and ParameterTypes. As parameters the registration accepts the callback of the algorithm, the category and parameter names. The same requirements for the callback as specified for the registration via constructor apply. The parameter names are accepted in a form of standard c++ array of strings of size equal to the number of parameters.
The basic registration is of a callback to the algorithm. The registration is equivalent to use of registration::AbstractRegister class. The call is to a function \emph{abstraction::AlgorithmRegistry::registerAlgorithm} which is parametrized with following types: Algorithm, ReturnType and ParameterTypes. As parameters the registration accepts the callback of the algorithm, the category and parameter names. The same requirements for the callback as specified for the registration via constructor apply. The parameter names are accepted in a form of standard c++ array of strings of size equal to the number of parameters.
The wrapper of alredy registered abstraction can be registered as algorithm via function call too. The function is \emph{abstraction::AlgorithmRegistry::registerWrapper} and it is templated by Algorithm and ParameterTypes. The call accepts a callback to the same delegate function as in the case of registration via constructor. Parameter names must be specified by a string array of size equal to the number of parameters (ParameterTypes template).
A wrapper of alredy registered abstraction can be registered as algorithm via function call too. The function is \emph{abstraction::AlgorithmRegistry::registerWrapper} and it is templated by Algorithm and ParameterTypes. The call accepts a callback to the same delegate function as in the case of registration via constructor. Parameter names must be specified by a string array of size equal to the number of parameters (ParameterTypes template).
The method registration, as last of options, is done via \emph{abstraction::AlgorithmRegistry::registerMethod} function. The template parameters are Algorithm, ObjectType, ReturnType, and ParameterTypes. The call parameters are a method pointer, a method name, and parameter names.
A method can be registered via \emph{abstraction::AlgorithmRegistry::registerMethod} function. The template parameters are Algorithm, ObjectType, ReturnType, and ParameterTypes. The call parameters are a method pointer, a method name, and parameter names. Note that method effectively needs extra parameter which is the object call the method on.
Registration functions do not register for normalization.
Registration of functions does not register for normalization.
\subsection{Registration of casts}
Full featured selection of algorithm to call, as implemented in c++ overload resolution algorithm, uses information about casts. Abstraction can keep track of casts available for such a purpose. The cast can also be executed manually when algorithm overload resolution would report multiple call candidates.
...
...
@@ -439,22 +481,57 @@ A variable of type \emph{ValuePrinterRegister} can be used to register a type pr
\subsubsection{Registration via function call}
A function \emph{ValuePrinterRegistry::registerValuePrinter} parametrized with type to print can be called directly to register the type for printing as well.
\section{Normalisation}
\label{section:normalisation}
Use of templates in the implementation requires the compiler to instantiate the templated code before it can be used in the executable. This mainly affects algorithms since they are processing templated datatypes. Internal use of algorithms implemented in the library can benefit from templates, the compiler can instantiate the algorithm template while preparing the executable. However, to be able to use templated algorithms in statically prepared environment, templates need to instantiated for some normalized types.
All datatypes can be normalized by means of specialisation of a templated class \emph{core::normalize}. The class must provide a public static method eval accepting a templated datatype it normalizes and it provides the same datatype with predefined, fixed template types.
Many normalization helpers are prepared for symbols, ranked symbols, states, their sets, etc.
The normalization class is used after any operation registered via abstraction that produces other than normalized type.
The library in its compiled version has all algorithms prepared for the normalized types by default.
\chapter{The query language}
This chapter will mostly focus on describing current status of the command line interface so called aql.
This chapter will mostly focus on describing current status of the command line interface so called aql. The command line interface was creted to replace the interface represented by multiple binaries. The command line interface uses the abstraction module and registered algorithms. The algorithms are available to be called with appripriate arguments. The language of the command line interface is similar to bash, featuring subqueries and pipes.
