ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
LUMIERA.clone/src/lib/iter-tree-explorer.hpp

189 lines
6.6 KiB
C++
Raw Normal View History

TreeExplorer: extended analysis regarding tree expanding and backtracking computation (#1117) This can be seen as a side track, but the hope is by relying on some kind of monadic evaluation pattern, we'll be able to to reconcile the IterExplorer draft from 2012 with the requirement to keep the implementation of "tree position" entirely opaque. The latter is mandatory in the use case here, since we must not intermingle the algorithm to resolve UI-coordinates in any way with the code actually navigating and accessing GTK widgets. Thus, we're forced to build some kind of abstraction barrier, and this turns out to be surprisingly difficult.
2017-11-17 21:43:50 +01:00
/*
ITER-TREE-EXPLORER.hpp - building blocks for iterator evaluation strategies
Copyright (C) Lumiera.org
2017, Hermann Vosseler <Ichthyostega@web.de>
This program is free software; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
/** @file iter-tree-explorer.hpp
** Building tree expanding and backtracking evaluations within hierarchical scopes.
** Based on the <b>Lumiera Forward Iterator</b> concept and using the basic IterAdaptor templates,
** these components allow to implement typical evaluation strategies, like e.g. depth-first or
** breadth-first exploration of a hierarchical structure. Since the access to this structure is
** abstracted through the underlying iterator, what we effectively get is a functional datastructure.
** The implementation is based on the IterStateWrapper, which is one of the basic helper templates
** provided by iter-adapter.hpp.
**
** @remark as of 2017, this template, as well as the initial IterExplorer (draft from 2012) can be
** seen as steps towards designing a framework of building blocks for tree expanding and
** backtracking algorithms. Due to the nature of Lumiera's design, we repeatedly encounter
** this kind of computation pattern, when it comes to matching flexible configuration against
** a likewise hierarchical and rules based model. To keep the code base maintainable,
** we deem it crucial to reduce the inherent complexity in such algorithms by clearly
** separate the _mechanics of evaluation_ from the actual logic of the target domain.
**
** # Iterators as Monad
** The fundamental idea behind the implementation technique used here is the \em Monad pattern
** known from functional programming. A Monad is a (abstract) container created by using some specific functions.
** This is an rather abstract concept with a wide variety of applications (things like IO state, parsers, combinators,
** calculations with exception handling but also simple data structures like lists or trees). The key point with any
** monad is the ability to \em bind a function into the monad; this function will work on the \em internals of the
** monad and produce a modified new monad instance. In the simple case of a list, "binding" a function
** basically means to map the function onto the elements in the list.
**
TreeExplorer: decide upon the steps towards implementation Here, the tricky question remains, how to relate this evalutaion scheme to the well known monadic handling of collections and iterators. It seems, we can not yet decide upon that question, rather we should first try to build a concrete implementation of the envisioned algorithm and then reconsider the question later, to what extent this is "monadic"
2017-11-18 03:00:59 +01:00
** ## Rationale
TreeExplorer: extended analysis regarding tree expanding and backtracking computation (#1117) This can be seen as a side track, but the hope is by relying on some kind of monadic evaluation pattern, we'll be able to to reconcile the IterExplorer draft from 2012 with the requirement to keep the implementation of "tree position" entirely opaque. The latter is mandatory in the use case here, since we must not intermingle the algorithm to resolve UI-coordinates in any way with the code actually navigating and accessing GTK widgets. Thus, we're forced to build some kind of abstraction barrier, and this turns out to be surprisingly difficult.
2017-11-17 21:43:50 +01:00
** The primary benefit of using the monad pattern is to separate the transforming operation completely from
** the mechanics of applying that operation and combining the results. More specifically, we rely on an iterator
** to represent an abstracted source of data and we expose the combined and transformed results again as such
TreeExplorer: decide upon the steps towards implementation Here, the tricky question remains, how to relate this evalutaion scheme to the well known monadic handling of collections and iterators. It seems, we can not yet decide upon that question, rather we should first try to build a concrete implementation of the envisioned algorithm and then reconsider the question later, to what extent this is "monadic"
2017-11-18 03:00:59 +01:00
** an abstracted data sequence. While the transformation to apply can be selected at runtime (as a functor),
** the monad pattern defines a sane way to represent partial evaluation state without requiring a container
** for intermediary results. This is especially helpful when
TreeExplorer: extended analysis regarding tree expanding and backtracking computation (#1117) This can be seen as a side track, but the hope is by relying on some kind of monadic evaluation pattern, we'll be able to to reconcile the IterExplorer draft from 2012 with the requirement to keep the implementation of "tree position" entirely opaque. The latter is mandatory in the use case here, since we must not intermingle the algorithm to resolve UI-coordinates in any way with the code actually navigating and accessing GTK widgets. Thus, we're forced to build some kind of abstraction barrier, and this turns out to be surprisingly difficult.
2017-11-17 21:43:50 +01:00
** - a flexible and unspecific source data structure needs to be processed
** - and this evaluation needs to be done asynchronously and in parallel (no locking, immutable data)
TreeExplorer: decide upon the steps towards implementation Here, the tricky question remains, how to relate this evalutaion scheme to the well known monadic handling of collections and iterators. It seems, we can not yet decide upon that question, rather we should first try to build a concrete implementation of the envisioned algorithm and then reconsider the question later, to what extent this is "monadic"
2017-11-18 03:00:59 +01:00
** - and a partial evaluation needs to be stored as continuation (not relying on the stack for partial results)
TreeExplorer: extended analysis regarding tree expanding and backtracking computation (#1117) This can be seen as a side track, but the hope is by relying on some kind of monadic evaluation pattern, we'll be able to to reconcile the IterExplorer draft from 2012 with the requirement to keep the implementation of "tree position" entirely opaque. The latter is mandatory in the use case here, since we must not intermingle the algorithm to resolve UI-coordinates in any way with the code actually navigating and accessing GTK widgets. Thus, we're forced to build some kind of abstraction barrier, and this turns out to be surprisingly difficult.
2017-11-17 21:43:50 +01:00
**
TreeExplorer: decide upon the steps towards implementation Here, the tricky question remains, how to relate this evalutaion scheme to the well known monadic handling of collections and iterators. It seems, we can not yet decide upon that question, rather we should first try to build a concrete implementation of the envisioned algorithm and then reconsider the question later, to what extent this is "monadic"
2017-11-18 03:00:59 +01:00
** @todo WIP-WIP-WIP initial draft as of 11/2017
TreeExplorer: extended analysis regarding tree expanding and backtracking computation (#1117) This can be seen as a side track, but the hope is by relying on some kind of monadic evaluation pattern, we'll be able to to reconcile the IterExplorer draft from 2012 with the requirement to keep the implementation of "tree position" entirely opaque. The latter is mandatory in the use case here, since we must not intermingle the algorithm to resolve UI-coordinates in any way with the code actually navigating and accessing GTK widgets. Thus, we're forced to build some kind of abstraction barrier, and this turns out to be surprisingly difficult.
2017-11-17 21:43:50 +01:00
**
TreeExplorer: decide upon the steps towards implementation Here, the tricky question remains, how to relate this evalutaion scheme to the well known monadic handling of collections and iterators. It seems, we can not yet decide upon that question, rather we should first try to build a concrete implementation of the envisioned algorithm and then reconsider the question later, to what extent this is "monadic"
2017-11-18 03:00:59 +01:00
** @see IterTreeExplorer_test
TreeExplorer: extended analysis regarding tree expanding and backtracking computation (#1117) This can be seen as a side track, but the hope is by relying on some kind of monadic evaluation pattern, we'll be able to to reconcile the IterExplorer draft from 2012 with the requirement to keep the implementation of "tree position" entirely opaque. The latter is mandatory in the use case here, since we must not intermingle the algorithm to resolve UI-coordinates in any way with the code actually navigating and accessing GTK widgets. Thus, we're forced to build some kind of abstraction barrier, and this turns out to be surprisingly difficult.
2017-11-17 21:43:50 +01:00
** @see iter-adapter.hpp
** @see itertools.hpp
** @see IterSource (completely opaque iterator)
**
*/
#ifndef LIB_ITER_TREE_EXPLORER_H
#define LIB_ITER_TREE_EXPLORER_H
#include "lib/error.hpp"
#include "lib/meta/function.hpp"
#include "lib/iter-adapter.hpp"
#include "lib/iter-stack.hpp"
#include "lib/meta/trait.hpp" ////////////////TODO
#include "lib/null-value.hpp" ////////////////TODO
#include "lib/util.hpp"
#include <boost/utility/enable_if.hpp> ////////////////TODO
#include <stack> ////////////////TODO
namespace lib {
namespace iter_explorer {
TreeExplorer: decide upon the steps towards implementation Here, the tricky question remains, how to relate this evalutaion scheme to the well known monadic handling of collections and iterators. It seems, we can not yet decide upon that question, rather we should first try to build a concrete implementation of the envisioned algorithm and then reconsider the question later, to what extent this is "monadic"
2017-11-18 03:00:59 +01:00
////////////TODO
TreeExplorer: extended analysis regarding tree expanding and backtracking computation (#1117) This can be seen as a side track, but the hope is by relying on some kind of monadic evaluation pattern, we'll be able to to reconcile the IterExplorer draft from 2012 with the requirement to keep the implementation of "tree position" entirely opaque. The latter is mandatory in the use case here, since we must not intermingle the algorithm to resolve UI-coordinates in any way with the code actually navigating and accessing GTK widgets. Thus, we're forced to build some kind of abstraction barrier, and this turns out to be surprisingly difficult.
2017-11-17 21:43:50 +01:00
}
/**
* Adapter to build a demand-driven tree expanding and exploring computation
* based on a custom opaque _state core_. TreeExploer adheres to the _Monad_
* pattern known from functional programming, insofar the _expansion step_ is
* tied into the basic template by means of a function provided at usage site.
*
* @todo WIP -- preliminary draft as of 11/2017
*/
template<class SRC
>
TreeExplorer: decide upon the steps towards implementation Here, the tricky question remains, how to relate this evalutaion scheme to the well known monadic handling of collections and iterators. It seems, we can not yet decide upon that question, rather we should first try to build a concrete implementation of the envisioned algorithm and then reconsider the question later, to what extent this is "monadic"
2017-11-18 03:00:59 +01:00
class IterTreeExplorer
TreeExplorer: extended analysis regarding tree expanding and backtracking computation (#1117) This can be seen as a side track, but the hope is by relying on some kind of monadic evaluation pattern, we'll be able to to reconcile the IterExplorer draft from 2012 with the requirement to keep the implementation of "tree position" entirely opaque. The latter is mandatory in the use case here, since we must not intermingle the algorithm to resolve UI-coordinates in any way with the code actually navigating and accessing GTK widgets. Thus, we're forced to build some kind of abstraction barrier, and this turns out to be surprisingly difficult.
2017-11-17 21:43:50 +01:00
: public IterStateWrapper<typename SRC::value_type, SRC>
{
public:
typedef typename SRC::value_type value_type;
typedef typename SRC::reference reference;
typedef typename SRC::pointer pointer;
/** by default create an empty iterator */
TreeExplorer: decide upon the steps towards implementation Here, the tricky question remains, how to relate this evalutaion scheme to the well known monadic handling of collections and iterators. It seems, we can not yet decide upon that question, rather we should first try to build a concrete implementation of the envisioned algorithm and then reconsider the question later, to what extent this is "monadic"
2017-11-18 03:00:59 +01:00
IterTreeExplorer() { }
TreeExplorer: extended analysis regarding tree expanding and backtracking computation (#1117) This can be seen as a side track, but the hope is by relying on some kind of monadic evaluation pattern, we'll be able to to reconcile the IterExplorer draft from 2012 with the requirement to keep the implementation of "tree position" entirely opaque. The latter is mandatory in the use case here, since we must not intermingle the algorithm to resolve UI-coordinates in any way with the code actually navigating and accessing GTK widgets. Thus, we're forced to build some kind of abstraction barrier, and this turns out to be surprisingly difficult.
2017-11-17 21:43:50 +01:00
/** wrap an iterator-like state representation
* to build it into a monad. The resulting entity
* is both an iterator yielding the elements generated
* by the core, and it provides the (monad) bind operator.
*/
explicit
TreeExplorer: decide upon the steps towards implementation Here, the tricky question remains, how to relate this evalutaion scheme to the well known monadic handling of collections and iterators. It seems, we can not yet decide upon that question, rather we should first try to build a concrete implementation of the envisioned algorithm and then reconsider the question later, to what extent this is "monadic"
2017-11-18 03:00:59 +01:00
IterTreeExplorer (SRC const& iterStateCore)
TreeExplorer: extended analysis regarding tree expanding and backtracking computation (#1117) This can be seen as a side track, but the hope is by relying on some kind of monadic evaluation pattern, we'll be able to to reconcile the IterExplorer draft from 2012 with the requirement to keep the implementation of "tree position" entirely opaque. The latter is mandatory in the use case here, since we must not intermingle the algorithm to resolve UI-coordinates in any way with the code actually navigating and accessing GTK widgets. Thus, we're forced to build some kind of abstraction barrier, and this turns out to be surprisingly difficult.
2017-11-17 21:43:50 +01:00
: IterStateWrapper<value_type, SRC> (iterStateCore)
{ }
private:
};
TreeExplorer: decide upon the steps towards implementation Here, the tricky question remains, how to relate this evalutaion scheme to the well known monadic handling of collections and iterators. It seems, we can not yet decide upon that question, rather we should first try to build a concrete implementation of the envisioned algorithm and then reconsider the question later, to what extent this is "monadic"
2017-11-18 03:00:59 +01:00
namespace iter_explorer {
/////TODO RLY?
TreeExplorer: extended analysis regarding tree expanding and backtracking computation (#1117) This can be seen as a side track, but the hope is by relying on some kind of monadic evaluation pattern, we'll be able to to reconcile the IterExplorer draft from 2012 with the requirement to keep the implementation of "tree position" entirely opaque. The latter is mandatory in the use case here, since we must not intermingle the algorithm to resolve UI-coordinates in any way with the code actually navigating and accessing GTK widgets. Thus, we're forced to build some kind of abstraction barrier, and this turns out to be surprisingly difficult.
2017-11-17 21:43:50 +01:00
using util::unConst;
using lib::meta::enable_if;
using lib::meta::disable_if;
using std::function;
using meta::_Fun;
}//(End) namespace iter_explorer : predefined policies and configurations
/* ==== convenient builder free functions ==== */
TreeExplorer: decide upon the steps towards implementation Here, the tricky question remains, how to relate this evalutaion scheme to the well known monadic handling of collections and iterators. It seems, we can not yet decide upon that question, rather we should first try to build a concrete implementation of the envisioned algorithm and then reconsider the question later, to what extent this is "monadic"
2017-11-18 03:00:59 +01:00
/*
TreeExplorer: extended analysis regarding tree expanding and backtracking computation (#1117) This can be seen as a side track, but the hope is by relying on some kind of monadic evaluation pattern, we'll be able to to reconcile the IterExplorer draft from 2012 with the requirement to keep the implementation of "tree position" entirely opaque. The latter is mandatory in the use case here, since we must not intermingle the algorithm to resolve UI-coordinates in any way with the code actually navigating and accessing GTK widgets. Thus, we're forced to build some kind of abstraction barrier, and this turns out to be surprisingly difficult.
2017-11-17 21:43:50 +01:00
template<class IT>
inline IterExplorer<iter_explorer::WrappedSequence<IT>>
exploreIter (IT const& srcSeq)
{
return IterExplorer<iter_explorer::WrappedSequence<IT>> (srcSeq);
}
template<class IT>
inline iter_explorer::DepthFirst<IT>
depthFirst (IT const& srcSeq)
{
return iter_explorer::DepthFirst<IT> (srcSeq);
}
template<class IT>
inline iter_explorer::BreadthFirst<IT>
breadthFirst (IT const& srcSeq)
{
return iter_explorer::BreadthFirst<IT> (srcSeq);
}
TreeExplorer: decide upon the steps towards implementation Here, the tricky question remains, how to relate this evalutaion scheme to the well known monadic handling of collections and iterators. It seems, we can not yet decide upon that question, rather we should first try to build a concrete implementation of the envisioned algorithm and then reconsider the question later, to what extent this is "monadic"
2017-11-18 03:00:59 +01:00
*/
TreeExplorer: extended analysis regarding tree expanding and backtracking computation (#1117) This can be seen as a side track, but the hope is by relying on some kind of monadic evaluation pattern, we'll be able to to reconcile the IterExplorer draft from 2012 with the requirement to keep the implementation of "tree position" entirely opaque. The latter is mandatory in the use case here, since we must not intermingle the algorithm to resolve UI-coordinates in any way with the code actually navigating and accessing GTK widgets. Thus, we're forced to build some kind of abstraction barrier, and this turns out to be surprisingly difficult.
2017-11-17 21:43:50 +01:00
} // namespace lib
#endif /* LIB_ITER_TREE_EXPLORER_H */
Reference in a new issue Copy permalink