Skip to content
Snippets Groups Projects
Commit 380c9a88 authored by Jan Trávníček's avatar Jan Trávníček
Browse files

more documentation

parent 7baa8f02
No related branches found
No related tags found
No related merge requests found
Pipeline #
......@@ -276,6 +276,24 @@ The language is described in more details later.
\chapter{Concepts used in the implementation}
 
\section{Components}
Many data structures are defined as a n-tuple where the components are of different types and have some defined constraints. The components concept is present to aid with design of data structures having this exact definition. A components concept is still in a stage of proof of concept, it does not support different types than sets and values. When extended, it will support maps, vectors, and trees to allow complete definition of most of data structures.
\subsection{Component as a base of datastructure}
Using the component requires to derive your datatype from a templated class \emph{code::Components}. The \emph{code::Components} class uses the \emph{Curiously recurring template pattern} by 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 of the component.
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 >
The internal type of the component must provide common interface required by the component behavior scheme. So far supported schemes are \emph{component::Set} and \emph{component::Value}. The component set scheme expects the internal datatype to implement interface of a set from the standard library. The componet value scheme expects the internal datatype to behave like primitive type.
The name of the component can be specified in two ways. Either it can be specified by class name, where typically the class used here is incomplete. Or more names can be given at once to signal there are more components having the same structure and behavior in the datatype definition. If more names are provided, the resulting components are instanciated for each name in a set and they are therefore independent instances.
\subsection{Access to component content}
Depending on the behavior scheme of the component, each component provides some simplified inteface to the underlying data type.
\subsection{Constraint specification}
 
\section{Normalisation}
\label{section:normalisation}
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment