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

Properly implement a bind macro for preprocessor constructs #20

Closed
irrequietus opened this issue Feb 22, 2014 · 4 comments
Closed

Properly implement a bind macro for preprocessor constructs #20

irrequietus opened this issue Feb 22, 2014 · 4 comments
Assignees
@irrequietus
Labels
feature ppmpf prioritized
Milestone
0.1

Comments

@irrequietus
Copy link
Owner

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.
@irrequietus irrequietus added this to the 0.1 milestone Feb 22, 2014
@irrequietus irrequietus self-assigned this Feb 22, 2014
irrequietus added a commit that referenced this issue Feb 22, 2014
@irrequietus
Several changes, preparing for n-ary implementation of the bind macro.
dc0cb88 
This commit introduces the PPMPF_BDS* constructs that are to be used in the
final version of "binding". The two macros already available in testing mode,
PPMPF_TUP_BIND and PPMPF_UTUP_BIND are the proof of concept but do not
respect n-arity. This commit paves the way for their final implementation
and deployment of said feature within high order function semantics at the
preprocessor level, and is related to issues #18 and #20.

Also introduced:

    *) PPMPF_NNX macro in core files (next of [0-9] single digits).
    *) Ability for function macro binding to deal with "constants", provided
       these are passed enclosed in a _(...) marker during the "binding"
       signature.
    *) Some initial workup on the way documentation is to be handled in
       odreex, starting with macros, in the new bind.hh ppmpf file.
@irrequietus
Copy link
Owner Author

The pbind branch as of commit dc0cb88 is to be dealing with this, thus what described in issue #18 for the M macro is to be resolved here. That issue should be closed after this one is dealt with.

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
Copy link
Owner Author

Commit 4834e89 makes PPMPF_MAP available in its initial incarnation and it is a bind - aware prototype of a high order function macro. Relocation of functionality within the ppmpf collection headers should be considered while transitioning into a "type" - aware system for the ppmpf collections involved as discussed in issue #6.

@irrequietus
Copy link
Owner Author

The previous work on PPMPF_TUP_BIND and PPMPF_UTUP_BIND is to be revised accordingly since commit 4834e89, with deprecation likely since they could be both supplanted by a newer PPMPF_BIND based on work done on PPMPF_BDS31.

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 22, 2014
@irrequietus
Making PPMPF_TMAP example deploy PPMPF_TFY and its metahandlers.
65e6cfb 
The implementation of PPMPF_TMAP is now dependent on its ppmpf typeid
"type" metahandlers for its functionality. It dispatches correctly to
either safe / unsafe tuples. Conceptually dealing with issue #18. The
last step will be to add expression support to the metahandlers, thus
resolving issue #20 definitively as well.
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
Copy link
Owner Author

Since commit 8c09a2a, the branch originating from commit dc0cb88 has been merged with the one from 55c113c and this issue becomes dependent upon the resolution of #6 and #18. The semantics for "binding" are complete. Thus, the _pbind_ branch as of 8c09a2a has been removed due to merging it with dc0cb88 into 8c09a2a.

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 prioritized
Projects
None yet
Milestone
0.1
Development

No branches or pull requests
1 participant
@irrequietus