P0578

[Michael Wong]

We were reading P0578R0 and we noticed that it says that anonymous functions are not currently supported by the proposal but are intended for a later paper.

We are interested in the ability to reflect on an anonymous function e.g  identify a lambda across code compiled by different compilers of potentially different ABIs.) We think this is useful for different compiler passing over the same code for the case where you might which to generate code for different target devices using a single source programming model.

In the ideal case we would like to be able to have a standard naming convention for lambda functions across compilers, however we understand that is a particularly difficult feat to accomplish, due to the difference in ABIs across compilers.

An alternative solution and reasonably simple elegant presents itself with static reflection and it would be to construct a type comprising of meta-objects that represents the lambda function and for this the current reflection information for classes would suffice as we believe that such a type could be constructed from such as get_source_line, get_source_column, get_source_filename and get_base_name of each member via get_accessible_member_types.

We are interested in what the current thoughts on supporting reflection for anonymous functions are and would be happy to contribute towards a future paper for this.

Please let us know.

Thanks.

Michael W.

[Axel Naumann]

Hi Michael!

Apologies for not answering within reasonable time.

On 02/25/2017 11:21 PM, Michael Wong wrote:
> We were reading P0578R0 and we noticed that it says that anonymous
> functions are not currently supported by the proposal but are intended
> for a later paper.

We (Matus, David and I) wanted to lay the foundation with P0194(R3), see
how it fares through SG7, Evolution, LEWG - i.e. whether this is
something that the committee can agree on for a TS.

We haven't traveled the rocky roads of LEWG yet ;-) but for the rest: so
far so good! Now we get carried away a bit, and we are planning to
propose static reflection for functions and hopefully lambdas in a
follow-up paper.

I think we know what we want and how to do it. Expect it in the next
mailing! And we'll share a sneak preview if we manage early enough
before the Toronto mailing deadline, to solicit feedback.


Cheers, Axel

> We are interested in the ability to reflect on an anonymous function
> e.g identify a lambda across code compiled by different compilers of
> potentially different ABIs.) We think this is useful for different
> compiler passing over the same code for the case where you might which
> to generate code for different target devices using a single source
> programming model.
>
> In the ideal case we would like to be able to have a standard naming
> convention for lambda functions across compilers, however we understand
> that is a particularly difficult feat to accomplish, due to the
> difference in ABIs across compilers.
>
> An alternative solution and reasonably simple elegant presents itself
> with static reflection and it would be to construct a type comprising of
> meta-objects that represents the lambda function and for this the
> current reflection information for classes would suffice as we believe
> that such a type could be constructed from such as get_source_line,
> get_source_column, get_source_filename and get_base_name of each member
> via get_accessible_member_types.
>
> We are interested in what the current thoughts on supporting reflection
> for anonymous functions are and would be happy to contribute towards a
> future paper for this.
> Please let us know.
>
> Thanks.
> Michael W.
>

> --
> 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+...@isocpp.org
> <mailto:reflection+...@isocpp.org>.
> To post to this group, send email to refle...@isocpp.org
> <mailto: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.

--

--
ROOT - http://root.cern
EP-SFT, CERN, 1211 Geneve 23, Switzerland
Tel: +41 22 7678225

[Michael Wong]

Thank you very much for that response. This is great news. We would like to help with such design and we may even manage to early implement in clang/llvm it as it is an extremely important use-case for us, for dynamically being able to switch the device compiler.

> an email to reflection+unsubscribe@isocpp.org
> <mailto:reflection+unsub...@isocpp.org>.

> To post to this group, send email to refle...@isocpp.org
> <mailto: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.

[Michael Wong]

Hi, Axel et al, we are wondering if you plan to post a lambda reflection paper and we would be interested in helping or give feedback.

We have a use-case to support this.

Thanks.

> <mailto:reflection+unsubscribe@isocpp.org>.

> To post to this group, send email to refle...@isocpp.org
> <mailto: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.

[Axel Naumann]

Hi Michael,

Are you claiming the winter is over and the mailing deadline is approaching?!

We should have something to share next week!

Cheers, Axel 

[Michael Wong]

Unfortunately, it is approaching rather fast and seem to accelerating towards us like light in the tunnel:) 

Hope all is well in lovely Swiss France canton and the tau muons are singing for you.

Yes, we love to collaborate.

[Axel Naumann]

Hi,

Here
https://bb.githack.com/karies/cxxstd-funcrefl/raw/HEAD/func-refl.html is
a preview (as in: this is work in progress!) of the function reflection
paper.

Please send your comments by Thursday (to the list or private - whatever
you prefer) so we have a chance to discuss your feedback internally and
actually react to it before the mailing deadline!

Cheers, Axel,
with Matus and David.

[Peter Bindels]

Hi Axel, others,

It's good to see a concrete proposal already appearing for static function reflection. I'm assuming up-front that this proposal is at least somewhat aligned with the pending proposal from Herb Sutter & Andrew Sutton.

In the proposal I see an OverloadSet, returned from reflexpr(name) whose only use is to pass it into a get_overloads to retrieve an ObjectSequence that's actually usable. Is this a candidate to perhaps make implied in the reflexpr(name)? What's the function of the OverloadSet being separate?

Which parts of the function set that could match an invocation by that name make it into the OverloadSet? Is it possible to get a hybrid overload set of members and nonmembers? What about ADL-findable but not normally included options? Is it (should it be) possible to reflect on operators (reflexpr(operator<<) for example)?

RecordMemberFunction seems to be missing predicates for &, && and noexcept member functions. & may come from RecordMember (perhaps an idea to link the paper that defines it?)

Is it an idea to consider adding a way to discover member function(s)? Right now you would be able to reflect them, but without knowing the names a priori, you would not be able to find them.

Is there any plan yet for a future reification proposal based on reflected (and possibly mutated) member functions, possibly in a constexpr block as alluded to by Herb Sutter in his keynote and  Louis Dionne in P0633?

Your link to open item #29 seems to have gone dead - http://cplusplus.github.io/concepts-ts/ts-active.html#29 . Looking on the page, it seems that it's no longer there at all.

Best regards,
Peter Bindels

[Anton Bikineev]

Hi,

Due to the lack of time, I just briefly looked through the proposal and the only thing I found missing is the ability to check whether a lambda is mutable or not (as long as Lambda is not RecordMemberFunction, we just can't query is_const on it).

By and large, the proposal is nice.

понедельник, 12 июня 2017 г., 12:55:30 UTC+3 пользователь Axel Naumann написал:

[Axel Naumann]

Hi Peter,

Thank you for your wonderful feedback! Comments inline:

On 06/13/2017 01:06 PM, Peter Bindels wrote:

Hi Axel, others,

It's good to see a concrete proposal already appearing for static function reflection.

"Already"? Ha! :-)

I'm assuming up-front that this proposal is at least somewhat aligned with the pending proposal from Herb Sutter & Andrew Sutton.

SG7 decided that P0194 and other proposals should progress independently, recognizing that the main difference is of syntactic nature. In that spirit you should continue to watch both.

In the proposal I see an OverloadSet, returned from reflexpr(name) whose only use is to pass it into a get_overloads to retrieve an ObjectSequence that's actually usable. Is this a candidate to perhaps make implied in the reflexpr(name)? What's the function of the OverloadSet being separate?

An OverloadSet also has a name. It is returned by more interfaces than just reflexpr(name): get_functions and get_conversion_op also return OverloadSets.

Which parts of the function set that could match an invocation by that name make it into the OverloadSet? Is it possible to get a hybrid overload set of members and nonmembers? What about ADL-findable but not normally included options?

The intent was that yes, those should be included in the OverloadSet. And thanks for pointing out that I forgot to spell that out!

Is it (should it be) possible to reflect on operators (reflexpr(operator<<) for example)?

Yes, and the paper now states that more clearly. Thanks!

RecordMemberFunction seems to be missing predicates for &, && and noexcept member functions. & may come from RecordMember (perhaps an idea to link the paper that defines it?)

Indeed, I had added them in the meantime as

struct has_lvalueref_qualifier

struct has_rvalueref_qualifier

Is it an idea to consider adding a way to discover member function(s)? Right now you would be able to reflect them, but without knowing the names a priori, you would not be able to find them.

See the section titled "Extending Record" - that should take care of it?

Is there any plan yet for a future reification proposal based on reflected (and possibly mutated) member functions,

Yes! And indeed, reification and modification of reflection entities as well as identifier generation are nicely intertwined.

possibly in a constexpr block as alluded to by Herb Sutter in his keynote and  Louis Dionne in P0633?

SG7 is still discussing that. My current understanding is that we might get a conservative approach (P0194-style) and a more risky but fundamental design (Herb) and independently a hana-style layer or alternative.

Note that I personally (and if I understand and remember correctly the same holds for my co-authors) am not against any of those. But I am absolutely positive that we should not wait until the "type or value TMP" discussion is settled, or until Herb has convinced the community that we need a fourth language in C++. What we are doing with out papers is get the *content* of reflection settled; the syntax can then be discussed (or alternatives added) at a later stage. This argument might not hold completely for Herb's and Andrew's proposal, which is more than a simply syntactic layer on top of our proposal, but they will benefit from us collecting (and restricting), naming and structuring the available operations, too.

Your link to open item #29 seems to have gone dead - http://cplusplus.github.io/concepts-ts/ts-active.html#29 . Looking on the page, it seems that it's no longer there at all.

Yup, it's completed! Thanks for pointing that out!

An updated version is available under the same link: https://bb.githack.com/karies/cxxstd-funcrefl/raw/HEAD/func-refl.html


Axel.

On Monday, June 12, 2017 at 11:55:30 AM UTC+2, Axel Naumann wrote:

Hi,

Here
https://bb.githack.com/karies/cxxstd-funcrefl/raw/HEAD/func-refl.html is
a preview (as in: this is work in progress!) of the function reflection
paper.

Please send your comments by Thursday (to the list or private - whatever
you prefer) so we have a chance to discuss your feedback internally and
actually react to it before the mailing deadline!

Cheers, Axel,
with Matus and David.

--
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+...@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.

[Axel Naumann]

Hi Anton,

(re-sending with proper identity)

Thanks, indeed that was missing!

I feel creative today, so I added:

struct is_call_operator_const;

I prefer that over sticking to the syntax level ("is_mutable"): it describes the effect, rather than using the keyword we happen to use for specifying it. This might also reduce confusion if asked in a class context.

An updated revision is now available at the same place: https://bb.githack.com/karies/cxxstd-funcrefl/raw/HEAD/func-refl.html

Cheers, Axel 

--
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+...@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.

[Guillaume Racicot]

Hi Michael,

Are function template, aside from specialized function, reflected too in the overload set?

If there is already reflection on template (classes), could we inspire us from that api?

Thanks.

[Roland Bock]

Hi Axel,

I have a question regarding the OverloadSet:
How (if at all) does ADL play into this? The overload set might depend
on the arguments I am using. Thus, it might be necessary to specify
those, too.


Other small comments:
"tuple is not a replacement for classes."
In terms of the synthesis aspect of reflection, this might be the most
important sentence of the paper :-)

"warnings exist to protected"
(typo)

"template <Record T> struct get_public_member_functions; template
<Record T> struct get_accessible_member_functions; template <Record T>
struct get_member_functions;"
These should probably be on individual lines.


Cheers,

Roland

>> <mailto:reflection+...@isocpp.org>.

>> To post to this group, send email to refle...@isocpp.org

>> <mailto: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.
>
> --
>
> --
> ROOT - http://root.cern
> EP-SFT, CERN, 1211 Geneve 23, Switzerland
> Tel: +41 22 7678225
>

> --
> 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+...@isocpp.org

> <mailto:reflection+...@isocpp.org>.

> To post to this group, send email to refle...@isocpp.org

> <mailto:refle...@isocpp.org>.

[Axel Naumann]

Hi Guillaume,

Since Michael is not one of the co-authors of P0194 / P0578 / P0385 I
take the liberty of replying to your email.

We do not have a proposal to reflect on templates, neither classes nor
functions. Only specializations (which includes what's commonly known as
"instantiations") can currently be reflected.

I would welcome a paper proposing static reflection of templates!

Axel.

[Axel Naumann]

Hi Roland,

On 18.06.17 08:03, Roland Bock wrote:
> I have a question regarding the OverloadSet:
> How (if at all) does ADL play into this? The overload set might depend
> on the arguments I am using. Thus, it might be necessary to specify
> those, too.

Absolutely. We might not make ADL happen in time for the paper deadline
(tonight)... The only way I can personally see is to throw in yet
another function reflection syntax:

reflexpr(foo)
reflexpr(int foo(int))
reflexpr(foo(expression))

The last one would return an OverloadSet that includes functions found
through ADL.

> Other small comments:> "tuple is not a replacement for classes."
> In terms of the synthesis aspect of reflection, this might be the most
> important sentence of the paper :-)

:-) Thanks.

> "warnings exist to protected"
> (typo)
>
> "template <Record T> struct get_public_member_functions; template
> <Record T> struct get_accessible_member_functions; template <Record T>
> struct get_member_functions;"
> These should probably be on individual lines.

Thank you for reporting these; they are now fixed.

Axel.