Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Create a type - like system for ppmpf macro structures #6

Closed
irrequietus opened this issue Jan 10, 2014 · 2 comments
Closed

Create a type - like system for ppmpf macro structures #6

irrequietus opened this issue Jan 10, 2014 · 2 comments
Assignees
@irrequietus
Labels
feature ppmpf
Milestone
0.1

Comments

@irrequietus
Copy link
Owner

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.
@ghost ghost assigned irrequietus Jan 10, 2014
@irrequietus irrequietus mentioned this issue Feb 9, 2014
Closed
@irrequietus
Copy link
Owner Author

Casting mechanisms from and to other "types" involved should be implemented, beyond those already present.

irrequietus added a commit that referenced this issue Mar 7, 2014
@irrequietus
Candidates for effective ppmpf bind support: PPMPF_BDS30, PPMPF_BDS31
9276298 
Several changes and additions in order for function binding notation to
be available in both separate and high order function macros as present
in ppmpf. Other changes in compilation flags during tests. This commit
affects issues #9, #18, #20 and relatively issue #6 as well given its
dependency upon supporting ppmpf function binding signatures in high
order function macros using that eventual macro "type" system.

Of special interest are the following details:

    1) Introduced the pfld constructs in odreex/ppmpf/kernel/pfld
       in order to ensure non conflicting expansions in deeply nested
       and highly interdependent macro constructs depending on recursive
       expansion. This will eventually change the purpose of the old
       <odreex/ppmpf/algorithms/fold.hh> contents to just folds and
       not holding key mechanisms for recursive expansion based 
       recursive application of macros when high order functions are
       deployed in ppmpf.
    2) The major candidate for implementing a high order map function
       over safe / unsafe tuples is the PPMPF_BDS31 macro which is to
       be used for evolving current PPMPF_TUP_MAP, PPMPF_UTUP_MAP into
       forms accepting both binding notation and plain old function
       macros.
    3) The function binding notation semantics for PPMPF_BDS31 are the
       following:
         *) Placeholders are comprised of a single or double underscore
            followed by a number in range [0,9]. Single underscore ones
            means that no removal of balanced parenthetical enclosure
            occurs. Double underscores remove said enclosure.
         *) Placeholder ranges of [_1,_9] and [__1,__9] are used as
            argument ordinals in final function application over the
            entire series of arguments involved.
         *) The constant placeholder is introduced as an underscored
            balanced parenthesis in the form of _(...) where ... can
            be substituted by any content by the end user. During
            argument substitution, the content will be passed as an
            argument without balanced parenthetical enclosure.
         *) The function meta - description in the "binding" signature
            for a given function f is expressed as a 2-tuple where the
            first item is the function macro identifier itself and the
            second item is a 2-sequence where the first item can only
            be of placeholder set {_0,__0}. The second item is actually
            a n-tuple of placeholders in range [_1,_9] and [__1,__9]
            in any combination with any number of constant placeholders.
    4) PPMPF_BDS30 is the prototype that is going to be deprecating the
       current proof of concept PPMPF_TUP_BINDER and PPMPF_UTUP_BINDER
       macros.
    5) When building tests, -fconstexpr-depth=1024 is choosen as the
       new default for constexpr default recursion depth and thus is
       from now on passed as a flag during compilation.

A test has been added especially in tests/ppmpf/bds31.cc for PPMPF_BDS31
that can be compiled and run with 'make just ppmpf/bds31.cc'. Of note,
there are still optimizations to be made to the constructs involved in
such an expansion mechanism.
irrequietus added a commit that referenced this issue Mar 8, 2014
@irrequietus
PPMPF_MAP as a first ppmpf bind - aware prototype.
4834e89 
With the work done on PPMPF_BDS31, a ppmpf branching expression was used
in order for the PPMPF_TUP_MAP / PPMPF_UTUP_MAP to become bind - aware.
The newer macro is at its 3rd generation and is to be the prototype
upon which PPMPF_TUP_MAP, PPMPF_UTUP_MAP and PPMPF_SEQ_MAP are going to
be unified and become bind - aware. Affects series of dependent issues
#6, #9, #18, #20. The macro has its own dedicated test that can be
checked with 'make just ppmpf/map.cc'. This macro is going to be used
as the model upon which the other high order function emulators are
going to evolved into macros with "binding" and "type" features like the
left and right folds, zip, zipwith.
@irrequietus irrequietus mentioned this issue Mar 8, 2014
Closed
irrequietus added a commit that referenced this issue Mar 10, 2014
@irrequietus
A "type" system for the preprocessor using ppmpf typeclauses.
6c9d125 
In relation to issue #6, ppmpf typeclauses refer to a 2-tuple of items
with the first being any kind of ppmpf collection, the second a decimal
number serving as a "type" identifier and referred to as typeid. This
concept is used in order to implement "overloadable" high order function
macros used in ppmpf internals, but it is more a convenient bypass than
anything else.
@irrequietus
Copy link
Owner Author

Since commit 6c9d125, this issue is now delegated to branch ptype.

irrequietus added a commit that referenced this issue Mar 10, 2014
@irrequietus
Using a PPMPF_TMAP prototype with ppmpf typeclauses.
6e7c6be 
Added to ppmpf typeclause tests as well, PPMPF_TMAP is an implementation
of the high order PPMPF_TUP_MAP and PPMPF_UTUP_MAP that makes use of the
ppmpf typeclauses produced by the PPMPF_STUP and PPMPF_UTUP constructors
for said ppmpf "types", per issue #6. PPMPF_TMAP can compose safely with
itself as well and always returns the correct ppmpf typeclause.

PPMPF_TMAP can be extended into an implementation taking into account
ppmpf typeclauses of sequences as well. That is the final goal within
this particular branch.
irrequietus added a commit that referenced this issue Mar 13, 2014
@irrequietus
Prototypical macro function metahandlers for PPMPF_TFY in PPMPF_TMAP.
dc9b361 
In order to pave the way for ppmpf expressions like "bind" to be used in
PPMPF_TFY controlled expressions, the function metahandlers to which
PPMPF_TFY delegates control of expansion should be the ones controlling
the expansion of a given function macro. As an example, PPMPF_TMAP_H1
and PPMPF_TMAP_H2 test handlers are rewired to detect a parenthesis in
place of a function as an "expression" and expanding to PPMPF_UNIT()
whenever that happens. In essence:

   1) Initially, the typeid is retrieved from the ppmpf typeclause
      containing the typeid and ppmpf collection data section through
      PPMPF_TFY.
   2) PPMPF_TFY dispatches to the right metahandler according to typeid
      retrieved from the ppmpf typeclause.
   3) Metahandlers (like PPMPF_TMAP_H0 and PPMPF_TMAP_H1) take over from
      PPMPF_TFY and dispatch to either the current implementations for
      their respective typeids or to PPMPF_UNIT in case an "expression"
      (right now just a fake one represented by the () token).

Practically, this means that the final effect of PPMPF_TFY is function
"transformation" and "type" manipulation fot whatever weight these
terms may carry at the preprocessor level. An interesting, functional
construct for essentially solving issues #6 and #20!
irrequietus added a commit that referenced this issue Mar 27, 2014
@irrequietus
Various prototypes for ppmpf binding and typeclauses.
8c09a2a 
This is an experimental merge with several other edits, layout changes
and other optimizations related to both the binder and typeclause
implementations for ppmpf (see #6,#18,#20). The PPMPF_TMAP prototype
has been substituted by the PPMPF_QMAP one which supports the following:

    1) Distinguishes between safe and unsafe ppmpt tuples through the
       use of typeclause constructors PPMPF_STUP, PPMPF_UTUP that have
       only to be used once (during the declaration of the ppmpf
       collections themselves, completely unrelated to PPMPF_QMAP).
    2) Plain function macro identifiers as well as complex expressions
       with ppmpf placeholders and their "dereferencing" semantics.

Other changes include:

    1) The <odreex/ppmpf/kernel/cpro/core.hh> has been reedited and
       fully documented to an in - house documentation format that is
       to be used by odreex for producing the documentation for the
       whole project.
    2) PPMPF_TYPEFY, PPMPF_QTAT have been added to facilitate typeclause
       dispatching and faster but limited range [0 - 9] index access
       for comma separated tokens in ppmpf tuples.
    3) The concept of multilevel function metahandlers is to take hold
       on typeclause dispatching. See PPMPF_MAP_MHD and PPMPF_MHD as
       initial implementations upon which PPMPF_QMAP depends in order
       to do typeclause dispatching.
       
Although successive refactorings are to deprecate all the temporaries
used for developing the PPMPF_QMAP prototype, they remain, with their
tests for the time being. The last thing remaining for PPMPF_QMAP is
integration with ppmpf sequences and thus, resolve the conceptual
underpinnings of issues #6,#18,#20.
irrequietus added a commit that referenced this issue Mar 27, 2014
@irrequietus
Merging resolves #6, resolves #18, resolves #20.
4319525
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@irrequietus irrequietus

Labels
feature ppmpf
Projects
None yet
Milestone
0.1
Development

No branches or pull requests
1 participant
@irrequietus