* _TypeAsValue_ borrows large parts of its inspirations from _Scheme_ ** i.e. there is no reason for stopping at this point
* analogously to arbitrary list count concatenation in Scheme's `append` ** implemented for `Concatenate` instead as it fits better with the structure between `Append` and `Concatenate`
* introduced `state::state_accessor` helper function and moved position logic into `updatePosition` * added `IsEqual` comparator and expressed other basic comparators in terms of itself
* i.e. separate namespaces and headers for _Tape_ and _State_ functions * `void` is now used as the `BLANK` field value
* as its name implies this function replaces the _nth_ element of a given list * added appropriate test case
* `ListIndex` already implements the necessary partial template specializations for finding elements matching a predicate * reimplemented `Cond` using `detail::find_variadic` as `Find` depends on `Apply` which in turn depends on `Cond` ** it is useful if core functionality such as the branched conditional `Cond` do not require higher order functionality such as `Find` *** otherwise one can not use core functionality in the implementation of higher order functionality * introduced `utility::predicate_guard` helper template ** checks a given value using a predicate and only forwards the value to the guarded function if this check is successful ** if check is unsuccessful it returns a surrogate value simmilar to `utility::predicate_assurance`
* analogously to `list-index` and `find` in SRFI-1
* `Fold` already implements the necessary partial specializations for traversing list structures
* new higher order list operation `ListIndex` returns the index of the first list element satisfying a given predicate function ** this enables finding the split index required for both `TakeWhile` and `DropWhile` ** actual list manipulation is then performed using lower order `Take` or `Drop` ** analogously to `list-index` in SRFI-1 ** added appropriate test case * added higher order predicate utility function `utility::predicate_assurance` ** as its name implies this function enables assuring that a value satisfies a given predicate *** if this is not the case a surrogate value is returned instead ** this is used to return a appropriate size value if the `ListIndex` call fails because no element satisfies its predicate ** `detail::predicate_negator` was moved from `Remove`'s implementation details into the newly introduced `utility` namespace *** as it is required by both `TakeWhile` and `DropWhile` in addition to `Remove` * continuation of 8e49cc6
* unifies the common functionality between `Take` and `Drop` * renamed `basic.h` to `length.h` as it only contains the `Length` implementation
* `detail::generate_nested_structure` offers a higher order nested structure constructor for procedural list generation * renamed `Fold` implementation details
* opens up the possibility of implementing different sort algorithms in this library * removed now unnecessary namespace prefixes
* continuation of 8e49cc6 * list constructor was generalized to a _variadic fold_
* continuation of 8e49cc6f8f
* i.e. instead of defining full class templates in the `detail` namespace we only define predicate helpers * I don't like how some symbols have to be prefixed with `tav::` in the `detail` namespace to prevent conflicts - this is one reason why as much implementation as possible should be moved to template aliases
* while class templates enable e.g. hiding implementation details they also require evaluation via `Eval` ** this clutters up the actual logic and is now hidden behind aliae that perform the evaluation
* replaces `typename *::type` constructs with `Eval` applications * aims to further unify function evaluation
* `type` is used to represent evaluation of a template * accessing the `function` doesn't evaluate it as it is the template itself
* analogously to `IsPair`
* moved internals into separate header i.e. the `detail` namespace relating to `Apply` * implemented automatic alias selection by implementing aliae of the basic variadic `type` template alias in different base classes ** variadic partial application is implemented in `detail::apply_variadic` *** `detail::apply_single` and `detail::apply_pair` define aliae to `detail::apply_variadic`'s `type` template alias *** both restricted aliae derive from `detail::apply_variadic` ** `Apply` derives from any of the aliae defining base classes depending on the count of placeholders as determined by `detail::count_placeholders` *** `Apply` is guaranteed to always be derived from `detail::apply_variadic` one way or the other * changed functions, test cases and examples depending on `Apply` accordingly ** `Length` had to be reimplemented without `Apply` as it doesn't allow usage of aliae expecting a different count of arguments anymore *** this is a advantage in the sense that core functionality of _TypeAsValue_ now doesn't depend on this complex partial application implementation anymore *** such functionality may be reimplemented separately from `Apply` * removed unnecessary `tav` namespace prefixes
* as it is commonly required functionality and as such should be provided by this library
* added further test cases for `Sort` as well as `Nth` aliae
* increases expressiveness in some contexts * renamed `Partition` list template parameter to avoid confusion
* otherwise a type conflict occurs when trying to instantiate a list of `void` ** this hinders construction of higher level functionality on top of `List`
* _Quicksort_ is the algorithm of choice ** it lends itself quite well to the _TypeAsValue_ approach because of its recursive nature ** this required implementation of a `Drop` counterpart to `Take` * the middle item of a given list is selected as the _pivot_ element * the `List` list contructor had to be expanded to allow `void` arguments inside its variadic parameter pack * added appropriate test cases
* this is analogous to _Scheme_ where a pair (dot-expression) is returned from a call to `cons` * `Head` and `Tail` are kept as direct references to the `CAR` and `CDR` values of a pair to match e.g. the math operators
* all other functions sans `Cons` are resolved when the respective member `*::type` is instantiated * this was changed soely to increase coherence
* both depict the very usecase partial function application via `Apply` is suited for
* analogously to how `Contains` is implemented as a wrapper around `Any` * added appropriate test case and lessened restrictions on `Contains`'s comparator
* as its name implies this function returns the longest initial prefix of a list that satisfies a given _Predicate_ * added appropriate test case
* added appropriate test case * other queries in `query.h` may be redefined in terms of `Find`
* `Remove` is a basic `Filter` alias that negates its predicate * `Partition` builds on both `Remove` and `Filter` to return both the elements satisfying a predicate and those which don't
* there is no reason to keep them in the same header
* enables construction of `Cons` structures using the same value type across all their elements
* this function illustrates the use case `Apply` is currently intended for * moved `Take` and `Nth` into separate files to resolve header resolution conflicts
* as its name implies this function counts the amount of elements satisfying a given _function_ * added appropriate test case
* as its name implies this function returns a list of `Count` elements of value `Element` * added appropriate test case
* added `Square` function to math operations header to facilitate a simple test case * added appropriate test case
* recursively generates a list of `Count` elements starting at `Initial` and consecutively adding `Step` ** as most functionality of this library this function was modeled after its _Scheme_ equivalent `iota` ** it may be used as the foundation of a set of higher order list generators including e.g. `list-tabulate` * added appropriate test cases
* added appropriate test case
* as its name implies this _function_ simplifies checking if a specific value is contained within a given list * updated `Map` to actually resolve the provided _function_
* it is not in itself a higher order function but only based on one
* in terms of `Fold` and `Map`, not the most efficient but reasonably concise * added appropriate test cases
* as its name implies this _function_ only returns elements which evaluate to _true_ when passed to a given _function_ ** this marks the moment where _TypeAsValue_ supports something _ConstList_ does not, i.e. primary goal is achieved *** namely returning different types depending on the actual _values_ of a _Cons_ structure * added appropriate test case