irrequietus / clause Goto Github PK

The library is currently being built with autotools. At its current stage and intended purpose, the library is mostly about headers, which means that it is easy to port it to a build system that is more cross-platform friendly (the library is not dependent upon system operations).

The custom code running the tests of the library right now, could be implemented as an integral part of the library itself, since these tests are already using the library itself. This would be seriously lowering the need for build system specific features to be available.

Complicated ppmpf constructs may present stark differences in expansion times between 4.7.x and 4.8.x C++11 modes in g++ as well as between clang++ and g++ 4.8.x. In summary:

• Both clang++ and earlier versions of g++ prove far more performant to g++ 4.8.x, at times by several factors in really complex macro expansions.
• From gcc bugzilla entries http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525 this is known to be a performance regression of the 4.8.x branch so far.
• Use of g++ 4.8.x with such constructs may result in out of memory errors, system lockup, memory fragmentation and other erratic behavior depending which worst - case scenario of said gcc preprocessor performance regression is met.
• The recommended fix for this kind of gcc performance regression is to pass during invocation of g++, the -ftrack-macro-expansion=0 flag in order to bypass macro tracking which heavily contributes to this behavior.

Therefore, if g++ is detected as the compiler used during configuration with autotools, this flag should be passed implicitly in order to deal with such a g++ performance regression.

There are several ways to document odreex source code, but certain kinds of constructs are likely to require special handling. In the end, this may require using a system proper to odreex just for that.

• 80 characters per line is maximum limit allowed in any kind of editor - friendly source code document and / or other non binary format, viewable and editable.
• The most likely outcome for documentation is to have a system that is odreex - specific.
• The ppmpf macros will probably be the first from which automated generation of documentation will happen.
• The constructs from the ample component will follow.
• The system should be unified, very simple and easy to deploy.

The ppmpf component contains a folding macro expansion construct that is used as the basis for implementing increased depths of recursive expansion (up to 10K elements) when emulating high order function macro application over ppmpf collections. The new one reaches a depth of 65536 elements.

• All affected macros should be rewired to using the new, fully "metafunction" macro based implementation of the previous construct.
• All new macros are to be using the new construct as their recursive application device.

The final token in a raw / unsafe ppmpf tuple, can also be a function macro identifier or a token consisting of special characters. That can cause some issues when empty checking is performed. Because recursive operations may yield such occurences, a "tuple" constructor is needed with the following semantics:

• When invoking PPMPF_TUPLE(...) a parenthesis enclosed series of comma separated , parenthesis enclosed tokens should be the final expansion of the macro, each extracted from VA_ARGS.
• When VA_ARGS is empty, the result of PPMPF_UNIT() is the final expansion of the macro.

Tests for ample and ppmpf are implemented in standalone, compilable files where headers are included from either / both projects in order to produce a single dedicated binary. Although they can be easily modified into headers - only mode, this has yet to be done, therefore:

• Refactor tests in such a way as to be header only, with no requirement of writing the actual source code for the final part of the test by the end user.
• Refactor tests so that they can also be generated during the build process itself.

The overloaded comma operator in declpack makes it useful for concatenating different declpack instantiations as well as individual types to newly combined packs. There are cases where this can be of use when creating a new pack by multiple subpacks or while one takes advantage of regular pack expansion semantics in combination with comma operators. This issue is about studying whether a += operator would be better to a , one.

The ppmpf collections and other macro constructs deployed in algorithms producing token sequences, should have a form that includes metadata that can be deployed by function macro overloads in order to pick the right kind of specialized metafunction to be used. Some hints on how this can be done:

• Using ppmpf collections with PPMPF_TUP_FOLDL and PPMPF_SEQ_FOLDL should be delegated to a PPMPF_FOLDL metafunction which will dispatch the metastructure to either PPMPF_TUP_FOLDL / PPMPF_SEQ_FOLDL.
• This solution should introduce the term "macro metastructure", alluding to a parenthesis enclosed triplet of elements where the first pair is comprised of metadata.

In a manner homologous to safe ppmpf tuples, ppmpf sequences should have their own "constructor" macro from a list of comma separated macro arguments.

When using high order macro functions, the only way to ensure secure expansion of complex function macros and their compositions upon a ppmpf tuple collection of any kind of token including special characters, is to have these become a parenthesis enclosed list of parenthesis enclosed items. In order to use them properly, the newer version of the folding macro construct should be used, with proper metafunctions.

Something like (char(*)[N])(nullptr) cannot exist under specific conditions that are of implicit conversion to positive integers / zero when used with such an array type; this is a technique that I often use for sfinae but non-compliant compilers might want to enable zero sized arrays (a GNU extension) by default. Thus, _compilers not respecting this, are not compliant to the standard_ and one of the reasons why -pedantic is on by default on clause. Making a note of this for future reference.

As already foreshadowed in the readme files, an exception in the spirit of the GCC linking exception is being considered given the metaprogramming nature of this project. Deciding the exact formulation of said exception is to be made prior to the first release of the project, until then this right is reserved by the original author (yours truly) and everythign is considered to be GPLv3+.

Within the ampl2-dev branch, commit 2cd8665 has introduced an idea I have been having for a lot of time regarding a specific manipulation algebra of parameter pack contents through range expressions and pattern matching sequences and generation patterns. I call these "annotated template parameter packs" and ample::atpp<X...> is a "container" type with eager semantics in its embedded template aliases serving as the necessary "metafunctions" (this is quite an inappropriate term despite it has unfortunately taken hold in C++ circles). This issue is for tracking the progress I make with them.

NOTE: following primitives are implemented so far:
==================================================

 1) atpp<X...>::repeat<N>        // repeat X... N times
 2) atpp<X...>::pattern_of<N>    // X... is repetition of first N types
 3) atpp<X...>::expand<N,M>      // [N,M) expansion
 4) atpp<X...>::generate<N,M,K>  // [N,M) expansion * K times repetition
 5) atpp<X...>::pattern_is<Y...> // constituting pattern of X... is Y...
 6) atpp<X...>::atpos_is<N,T>    // at index N, we have type T
 7) atpp<X...>::atpos<N>         // get the type at index N
 8) atpp<X...>::insert<N,T>      // at index N insert type T
 9) atpp<X...>::insert<N,T...>   // at index N insert pack T...
10) atpp<X...>::replace<N,T...>  // T... replaces [N, N + sizeof...(T))
11) atpp<X...>::remove<N,M>      // [N,M) removed from T...
12) atpp<X...>::remove<N>        // [N,N+1) removed from T... (just N)
13) atpp<X...>::contains<T>      // natural<N> where N = occurences of T
14) atpp<X...>::indices_of<T>    // to intgr_seq<N...>, N... = indices
15) atpp<X...>::uniques          // remove all duplicates from X...
16) atpp<X...>::uniques_as<W>    // remove duplicates from X..., wrap to W
17) atpp<X...>::filter<F>        // Predicate yielding boolean<B> equivalent
18) atpp<X...>::foldl<F,S>       // left fold of F over X... with initial S
19) atpp<X...>::foldl_of<F>      // left fold of F over X..., gets own S
20) atpp<X...>::foldr<F,S>       // right fold of F over X... with initial S
21) atpp<X...>::foldr_of<F>      // tight fold of F over X..., gets own S
22) atpp<X...>::fmap<F>          // F's oprt_apply<X>::type...
23) atpp<X...>::reverse          // X... sequence reversed (last is first)
24) atpp<X...>::split_left<N>    // [0,N) X... expansion
25) atpp<X...>::split_rght<N>    // [N,sizeof...(X)) X... expansion
26) atpp<X...>::push_back<T...>  // atpp<X...,T...>
27) atpp<X...>::push_frnt<T...>  // atpp<T...,X...>
28) atpp<X...>::pop_back<N>      // remove last "N" types, default is 1
29) atpp<X...>::pop_frnt<N>      // remove first "N" types, default is 1

This is more of a convenience feature; when declaring a test for clause::ample:: namespace and other template metaprogramming components, allow for multiple invocations of this boilerplate generating macro just like CLAUSE_TEST_TYPE; the code for doing so already allows it beyond its canonical use (passing a comma separated sequence of C++-compatible identifiers) but it needs a few tweaks.

Given two internal ppmpf number representations, implement modulo operation, nothing more.

While clause has good code in ppmpf and ample with each of them having full tests for everything they are implementing, we need more examples of basic use for meta-programming oriented users.

Semantics of clause::ample are cohere and complete for production use, however there are needs for certain optimizations as well as extension of purpose into something more than the usual things "C++ template metaprogramming" libraries are known for. Making this issue for tracking necessary notes, if anything important applies outside of what comments offer.

Since commit 820cb0b, support for both vertical and horizontal structure preserving transformations of token lists has been completed. A series of examples is needed for the vertical constructs as well as easy tests (horizontals have their own, but verticals are more complicated to appreciate). This should be done in parallel of complex interactions between the ppmpf macro set identifiers and PPMPF_VXPP_FMAP for the purposes of function macro composition. I am going to use this issue as a guideline for this, in a separate repository branch. Take note that there are many hidden features in commit 820cb0b which need time to be fleshed out properly.

When horizontal pattern expansion was originally implemented, number representations where initially limited as ppmpf 4-sequences (four digits separately enclosed in parentheses), however vertical expansion can deal with up to ppmpf 5-sequences for their number representation. Those two should be fully compatible so that preprocessor number abstractions are used seamlessly between the two different mechanisms of pattern generation.

Introduce a basic algorithm for doing multiplication using the internal number representation in ppmpf, with export to human - readable decimal format available.

When applying high order functions to unsafe tuples, current implementations always convert unsafe tuples to safe tuples, while in other functions like zip and zipwith convert from safe to unsafe tuple items from which the result of application is comprised of. It must be made so that the the two kinds of ppmpf tuples used do not “cast” to other “kinds” but remain of the same “kind” during application of high order functions, unless there is specific imposition from the programmer.

Up to a point, things like C++17 folding expressions feature can be (partially) used for metaprogramming purposes in implementing catamorphisms, despite it was mainly designed for easing out features like... "concepts". Currently clause has adopted by default C++14. With compiler evolution into the newer standard this and features like that will be adopted while offering where possible the usual recursive instantiation alternative for previous standards. This is a very loose guideline so far and this issue is for tracking a series of changes that might occur while C++17 becomes better supported by compilers.

Currently, header guards start with _ and that doesn't sit well with my own overflowing pedantry (despite I have willfully ignored it, as well as the compilers don't give 1 cent about it even in super pedantic mode). An easy fix that must be done now that the library is being reworked upon.

Mainly for debugging purposes; far too often during bleeding edge development in branches it is needed to see the error of the compiler instead of having it written down in the errors.log file. On certain occasions we cause the compilation error deliberately for development purposes.

The high order function zipwith should be implemented, ranging from 2 to 9 ppmpf collections. The zip part is to emerge from the same implementation.

Already since quite a few commits, odreex is being documented with specific /*~ ... */ sections that have a prototypical "language" for describing what happens in the code. Those will be used for producing the documentation out of odreex source code properly. No external dependencies are to be required. An extracting mechanism / documentation generator for such sections should be implemented within the library itself. Currently, said sections wherever they appear are very loosely specified and are in constant flux.

By default, the makefile produced uses ANSI colors when the tests / library are being built.

There is a flag in the configure script that can be used to enable / disable ANSI colors but it affects test binaries run after the build phase.

Make sure that when colors are enabled, they are enabled for both while building and while the tests are executed.

Given two ppmpf internal representations of numbers, return the result of integer division.

Given that FLOSS compilers like g++ and clang++ are towards full C++14 support (i.e. clang++ 3.4 onwards, g++ 4.9.x onwards), amendments should be made to the autotools based build system to account for that fact prior to actually deploying C++14 specific code.

Since commit cab781b, ample has got several enhancements and changes, most importantly for making it compatible with the template meta-programming model that we are to follow. Examples beyond what is presented in the commit are necessary and of course tests.

There have been changes and there will be changes that will supercede some request-like issues that have zombied out. This issue is for handling them properly.

After work done on the experimental branches has been merged to mainline, title says it all: more documentation about that feature, should be made evident on the project landing page.

While transitioning to the newer implementations of ppmpf macro functions in ppmpf sequences, some functions are broken / introduce regressions since commit 0e5c01b. A few notes on this important bug:

• the successive merge to the devbox branch resulted to a broken devbox for the time being.
• some functionality got temporarily broken during transition due to 0e5c01b.
• it is a major regression for the ppmpf component.
• gets full priority since it affects quite a few ppmpf functions, like atpos, zip.
• most importantly, the master branch is completely unaffected by this.

In commit 55c113c proof of concept implementations of a "bind" macro for safe and unsafe (raw) ppmpf tuples was introduced, while studying tuple semantics in issue #18 . The goal of this issue will be met once said binding macros become available with the semantics already discussed in #18 and related commits in high order function emulation within ppmpf.

Once ppmpf high order macros are complete, transit to deploying them instead of the initial repeater macro, while also removing it from macro core.

Some development policy guidelines is in progress of deployment:

• Only two git branches get infinite lifetime in the main development git repository, master and devbox.
• The default branch is master, always guaranteed to be fully functional and compilable as a library.
• The master branch is kept as a release - worthy level branch.
• The devbox branch is a parallel to the default branch but it contains several features that have just been merged from other branches, public or private that could introduce faults.
• All branches merged to devbox must be accompanied by their related tests.
• Branches outside master and devbox are not required to have tests and are ephemeral in lifetime, depending on the issue they deal with.