Functions and Closure Type reflection (for discrete-event modeling)

[Roman Popov]

Hello,

Current reflection implementation (https://github.com/matus-chochlik/clang ) does not support reflecting functions and ClosureTypes. Is there a plan to enable such functionality? What will be possible? - reflecting function parameters, list of captures in closure, local variables?

In particular, I’m looking to solve very common problem of discrete-event DSLs: modeling combinatorial processes. In combinatorial process output is a pure function of inputs, so if some input changes output must be recalculated. If a combinatorial process is modeled with C++ function you will need somehow extract list of variables used (read) in this function. In some languages this is possible with introspection, for example in Python. MyHDL http://myhdl.org/ is a discrete-event modeling library for Python built using introspection, decorators and coroutines.

Unfortunately, there is no way in C++ to extract variables that are read in some particular function. So C++ DSL user has to specify such “lists of inputs” explicitly.

For example in SystemC (http://accellera.org/downloads/standards/systemc)  I can model two-input multiplexer this way (with C++03):

sc_signal <T> in0, in1, out;  // sc_signal models a “wire”
sc_signal <bool> sel;

void mux() {  out = sel ? in0 : in1;  } // function that models mux behaviour

SC_METHOD(mux); // Creates a process (registers a function in discrete-event scheduler)
sensitive << in0 << in1 << sel;  //  sets a “sensitivity list” ( ~ a list of inputs ) for created process

As you may notice this is quite verbose. And error-prone: you can easily forget to specify some input in sensitivity list and have very hard to debug behavior.

So I’m researching if there is a way to invent a better syntax using lambdas and reflection.

[Matus Chochlik]

Hi Roman,

On Sun, Jan 8, 2017 at 6:21 AM, Roman Popov <random...@gmail.com> wrote:

Hello,

Current reflection implementation (https://github.com/matus-chochlik/clang ) does not support reflecting functions and ClosureTypes. Is there a plan to enable such functionality? What will be possible? - reflecting function parameters, list of captures in closure, local variables?

We are planning to add function reflection, actually the current implementation already internally defines some meta-function concepts. You can get metaobjects satisfying such concepts by getting the scope of reflected local variables or type aliases. But direct reflection by the reflexpr operator is currently disabled (so that we don't introduce a breaking change in the future).

When completed you should be able at least to get the return type, list of parameters and some "inherited" meta-data like scope or name (except for lambdas which will not be meta-Named). A meta-Parameter will be a either a specialization of meta-Variable or something similar (we are not sure what to do with the `get_pointer` operation with function parameters and local variables).

As for lambdas I'm not sure yet whether to reflect them like anonymous types with a function call operation or as functions.

 

In particular, I’m looking to solve very common problem of discrete-event DSLs: modeling combinatorial processes. In combinatorial process output is a pure function of inputs, so if some input changes output must be recalculated. If a combinatorial process is modeled with C++ function you will need somehow extract list of variables used (read) in this function. In some languages this is possible with introspection, for example in Python. MyHDL http://myhdl.org/ is a discrete-event modeling library for Python built using introspection, decorators and coroutines.

Unfortunately, there is no way in C++ to extract variables that are read in some particular function. So C++ DSL user has to specify such “lists of inputs” explicitly.

For example in SystemC (http://accellera.org/downloads/standards/systemc)  I can model two-input multiplexer this way (with C++03):

sc_signal <T> in0, in1, out;  // sc_signal models a “wire”
sc_signal <bool> sel;

void mux() {  out = sel ? in0 : in1;  } // function that models mux behaviour

SC_METHOD(mux); // Creates a process (registers a function in discrete-event scheduler)
sensitive << in0 << in1 << sel;  //  sets a “sensitivity list” ( ~ a list of inputs ) for created process

As you may notice this is quite verbose. And error-prone: you can easily forget to specify some input in sensitivity list and have very hard to debug behavior.

So I’m researching if there is a way to invent a better syntax using lambdas and reflection.

HTH,

--Matus

[Roman]

Thanks Matus,

As for lambdas I'm not sure yet whether to reflect them like anonymous types with a function call operation or as functions.

Personally I would vote for option 1 with anonymous type. And this is consistent with standard, that defines that lambda returns functor.

As I mentioned in my original email, I want in particular to get list of captures in metadata. 

It will be super-cool if it will be possible to distinguish if some capture is mutated or not inside lambda function. But I understand it can be probably far beyond current proposal.

Example:

[&] () { x = a.non_const_method() + b.const_method(); }

in that case for x and a can be captured by reference, and b by const reference. 

-Roman 

[Anton Bikineev]

Hi Matus,

Just wondering, when do you plan on adding support for reflecting functions to the proposal or the repo?

Thanks.

воскресенье, 8 января 2017 г., 14:33:07 UTC+7 пользователь Matúš Chochlík написал:

[Matus Chochlik]

Hi Anton,

With the current proposal we are focusing on getting a TS. If that happens (hopefully in Kona) then we will start adding new features, eventually including also the reflection of functions.

I'm pretty busy with my day job at the moment, so no promises about the implementation, but when I have some free time I will have a look at that too.

Regards,

--Matus

--
You received this message because you are subscribed to the Google Groups "SG 7 - Reflection" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reflection+unsubscribe@isocpp.org.
To post to this group, send email to refle...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/reflection/.
For more options, visit https://groups.google.com/a/isocpp.org/d/optout.

--

-- Matus Chochlik

[Anton Bikineev]

Thanks, Matus,

It's nice to know that P0194 is going to be a TS in upcoming meetings.

воскресенье, 12 февраля 2017 г., 22:26:29 UTC+7 пользователь Matúš Chochlík написал:

To unsubscribe from this group and stop receiving emails from it, send an email to reflection+...@isocpp.org.

To post to this group, send email to refle...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/reflection/.
For more options, visit https://groups.google.com/a/isocpp.org/d/optout.

--

-- Matus Chochlik

[Matus Chochlik]

Hi Anton,

so, we've just had a meeting with Axel and David and we've decided that at the Kona meeting the most importatnt thing is to get feedback about the current wording from EWG/LEWG, then for the next meeting (Toronto) we will add function (and possibly constructor) reflection and then we are going to push for a TS (so that the TS includes function reflection, and possibly more).

BR,

--Matus

[Anton Bikineev]

Hi Matus,

Thanks for update!

вторник, 14 февраля 2017 г., 0:20:32 UTC+7 пользователь Matúš Chochlík написал: