Date: Mon, 22 Feb 2021 00:27:45 +0000
Patterns: Yes, reflection+generation will let us write lots of* patterns as libraries, and even many language features as libraries, and that's huge. (* not "all"... careful not to oversell)
Examples: Yes, please be example-driven. Most of the page count of my 45-page P0707<http://wg21.link/p707> is examples with full code, because I spent a lot of time trying out how to write specific patterns (many of them compiling and running using an initial prototype) before I felt the paper was ready to publish as an R0. In fact those examples take up most of the 45-page paper, including that I wrote code for the following:
* interface
* base_class
* final
* ordered
* value (aka regular)
* struct (plain_struct to avoid the keyword)
* copyable_pointer
* enum_class
* flag_enum
* bitfield
* union (safe_union to avoid the keyword)
* namespace (namespace_class to avoid the keyword)
* signal / slot
* property
This was a lot of work, and much of the P0707-syntax code should translate well to another syntax so I hope this can help accelerate others writing examples in their own syntax.
A request please: If you're proposing a syntax, please try to demonstrate at least some of the P0707 examples in your alternative syntax. It would be super useful to see what's easier/different - I'd love to see a Tony table of a P0707 example compared to the equivalent in another proposal!
I would be happy to help and answer questions if you like, just reach out privately please.
Herb
> -----Original Message-----
> From: SG7 <sg7-bounces_at_[hidden]> On Behalf Of David Rector via SG7
> Sent: Sunday, February 21, 2021 3:13 PM
> To: Ville Voutilainen <ville.voutilainen_at_[hidden]>
> Cc: David Rector <davrec_at_[hidden]>; Andrew Sutton via SG7
> <sg7_at_[hidden]>
> Subject: Re: [SG7] P2320: "The Syntax of Static Reflection" feedback request
>
>
>
> > On Feb 21, 2021, at 4:14 PM, Ville Voutilainen
> <ville.voutilainen_at_[hidden]<mailto:ville.voutilainen_at_[hidden]>> wrote:
> >
> > On Sun, 21 Feb 2021 at 22:54, David Rector <davrec_at_[hidden]<mailto:davrec_at_[hidden]>> wrote:
> >> Well said. Some leisurely thoughts expanding on this:
> >>
> >> Note too that such a metafunction, properly implemented, would indeed
> make that design pattern /obsolete/ - all the user need do is #include the
> right header and they can type `a + b + ...` to their heart's content, blissfully
> ignorant of the meaning of a "Mediator" and an "Observer" and all the
> expertise and manual labor the previous generation needed to code such
> things.
> >>
> >> Indeed, I would argue is that reflection + injection, properly implemented,
> might well be able to make *every* design pattern obsolete - if it qualifies
> as a "pattern" in any sense, that means it is some call to a metafunction, and
> the only question is whether the programmers themselves must serve as that
> "metafunction", or if they are allowed to just write that metafunction
> explicitly and grab a beer.
> >
> > Well, yeah. Design patterns *are* obsolete in some more powerful
> > languages; instead of being recipes for implementing patterns in
> > various ways with various trade-offs, they're just code where those
> > trade-offs are customizations points of the algorithm. :)
> >
> > As a side note, some of us do this already, to the extent the language
> > limitations allow it. We had a particular policy in multiple places I
> > worked in, which was "never (try to) make your type a Singleton, use
> > ourcompany::Singleton<YourType>.
> > Also, please leave it up to the application programmer to decide how
> > many of YourTypes should exist in their program, and please never make
> > that decision for them." Various other oft-mentioned patterns are
> > feasible to implement with such a common library type/wrapper, but
> > reflection+injection opens quite some doors towards that ability. Like
> > Proxies and Mediators and Template Methods and Bridges etc.
> >
> >> I would thus argue the best source for generating examples is thus any
> design pattern textbook: try to write each one as a metafunction, and thus
> render knowledge of it obsolete altogether.
> >
> > It's certainly one source. The best, I don't know - things like
> > serialization and persistence are oft-mentioned examples of problems
> > where reflection/injection is a big help, but they aren't necessarily
> > well-represented in pattern books.
>
> Those sound great. Why not try writing one, using the new syntax?
>
> I think more of us be following Roland's example, trying to actually implement
> these things, and presenting the results to the list. It's a bit strange to be
> considering syntax changes without seeing it in action in large, real-world test
> cases.
>
> And as Roland found, trying to implement these real world cases often leads
> us to places the proposals have overlooked, thus identifying deeper issues.
>
> And beyond that, exchanging code instead of words would be a good way to
> lower the temperature in here and keep things in focus.
>
> But Roland can't be the only one.
>
> I think I've said my peace and presented a useful test case of my own so I'll
> bow out here and leave space for others, thanks all,
>
> Dave
>
> >
> >> FWIW, this belief is why I spent a year awhile back pretty much just
> learning clang and implementing the most general possible alternative to
> Andrew's, without much regard to syntax or cleanliness. The resulting ugly
> "glorified preprocessor"/string mixin approach is a standard by which I think
> Andrew's or any other alternative must be measured, and I will never be okay
> with any alternative that is not as capable as it, no matter how many people I
> admire and respect line up on the other side.
> >>
> >> But I would still very much welcome *improvements* on it that don't
> sacrifice its capabilities - it is definitely not without its problems; e.g. recall
> Richard's line that "a good metaprogram is semantic" - if indeed the
> "semantic" approach could be accomplished without losing the capabilities of
> the "syntactic" metaprogramming approach, I agree it is a big improvement,
> and thus Andrew's endeavor to develop such a semantic approach is certainly
> worthwhile, though incomplete at this point.
> >>
> >> The challenge Andrew et al will face, it seems to me, is that, to implement
> injection properly in things like Sum<T,U> and PreCalcdSum<T,U> and other
> still more complex examples, you really just need to be able to write multiple
> statements in "meta" space, complete with meta variable declarations,
> control flow statements, etc. - *in the midst of writing arbitrary code *in
> "non-meta" space - i.e. in the midst of writing expressions, or initializers, or
> base classes.
> >
> > Well.. I do expect to be able to inject function definitions, but I do
> > expect to do that semantically, meaning that I inject code fragments
> > that have injections in them, as opposed to injecting strings.
>
> --
> SG7 mailing list
> SG7_at_[hidden]<mailto:SG7_at_[hidden]>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.is<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg7&data=04%7C01%7Chsutter%40microsoft.com%7C7d9768cfb6dd4e2b5d4808d8d6be4a2a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637495460100701888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=viB2O0nxZgLwmc8OXoXOSZl6UX71Ea34cMn6THvLBYA%3D&reserved=0>
> ocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg7&data=04%7C01%7Chsutter%4<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg7&data=04%7C01%7Chsutter%40microsoft.com%7C7d9768cfb6dd4e2b5d4808d8d6be4a2a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637495460100701888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=viB2O0nxZgLwmc8OXoXOSZl6UX71Ea34cMn6THvLBYA%3D&reserved=0>
> 0microsoft.com%7C7d9768cfb6dd4e2b5d4808d8d6be4a2a%7C72f988bf86f141<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg7&data=04%7C01%7Chsutter%40microsoft.com%7C7d9768cfb6dd4e2b5d4808d8d6be4a2a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637495460100701888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=viB2O0nxZgLwmc8OXoXOSZl6UX71Ea34cMn6THvLBYA%3D&reserved=0>
> af91ab2d7cd011db47%7C1%7C0%7C637495460100701888%7CUnknown%7CT<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg7&data=04%7C01%7Chsutter%40microsoft.com%7C7d9768cfb6dd4e2b5d4808d8d6be4a2a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637495460100701888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=viB2O0nxZgLwmc8OXoXOSZl6UX71Ea34cMn6THvLBYA%3D&reserved=0>
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg7&data=04%7C01%7Chsutter%40microsoft.com%7C7d9768cfb6dd4e2b5d4808d8d6be4a2a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637495460100701888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=viB2O0nxZgLwmc8OXoXOSZl6UX71Ea34cMn6THvLBYA%3D&reserved=0>
> VCI6Mn0%3D%7C1000&sdata=viB2O0nxZgLwmc8OXoXOSZl6UX71Ea34cM<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg7&data=04%7C01%7Chsutter%40microsoft.com%7C7d9768cfb6dd4e2b5d4808d8d6be4a2a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637495460100701888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=viB2O0nxZgLwmc8OXoXOSZl6UX71Ea34cMn6THvLBYA%3D&reserved=0>
> n6THvLBYA%3D&reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg7&data=04%7C01%7Chsutter%40microsoft.com%7C7d9768cfb6dd4e2b5d4808d8d6be4a2a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637495460100701888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=viB2O0nxZgLwmc8OXoXOSZl6UX71Ea34cMn6THvLBYA%3D&reserved=0>
Examples: Yes, please be example-driven. Most of the page count of my 45-page P0707<http://wg21.link/p707> is examples with full code, because I spent a lot of time trying out how to write specific patterns (many of them compiling and running using an initial prototype) before I felt the paper was ready to publish as an R0. In fact those examples take up most of the 45-page paper, including that I wrote code for the following:
* interface
* base_class
* final
* ordered
* value (aka regular)
* struct (plain_struct to avoid the keyword)
* copyable_pointer
* enum_class
* flag_enum
* bitfield
* union (safe_union to avoid the keyword)
* namespace (namespace_class to avoid the keyword)
* signal / slot
* property
This was a lot of work, and much of the P0707-syntax code should translate well to another syntax so I hope this can help accelerate others writing examples in their own syntax.
A request please: If you're proposing a syntax, please try to demonstrate at least some of the P0707 examples in your alternative syntax. It would be super useful to see what's easier/different - I'd love to see a Tony table of a P0707 example compared to the equivalent in another proposal!
I would be happy to help and answer questions if you like, just reach out privately please.
Herb
> -----Original Message-----
> From: SG7 <sg7-bounces_at_[hidden]> On Behalf Of David Rector via SG7
> Sent: Sunday, February 21, 2021 3:13 PM
> To: Ville Voutilainen <ville.voutilainen_at_[hidden]>
> Cc: David Rector <davrec_at_[hidden]>; Andrew Sutton via SG7
> <sg7_at_[hidden]>
> Subject: Re: [SG7] P2320: "The Syntax of Static Reflection" feedback request
>
>
>
> > On Feb 21, 2021, at 4:14 PM, Ville Voutilainen
> <ville.voutilainen_at_[hidden]<mailto:ville.voutilainen_at_[hidden]>> wrote:
> >
> > On Sun, 21 Feb 2021 at 22:54, David Rector <davrec_at_[hidden]<mailto:davrec_at_[hidden]>> wrote:
> >> Well said. Some leisurely thoughts expanding on this:
> >>
> >> Note too that such a metafunction, properly implemented, would indeed
> make that design pattern /obsolete/ - all the user need do is #include the
> right header and they can type `a + b + ...` to their heart's content, blissfully
> ignorant of the meaning of a "Mediator" and an "Observer" and all the
> expertise and manual labor the previous generation needed to code such
> things.
> >>
> >> Indeed, I would argue is that reflection + injection, properly implemented,
> might well be able to make *every* design pattern obsolete - if it qualifies
> as a "pattern" in any sense, that means it is some call to a metafunction, and
> the only question is whether the programmers themselves must serve as that
> "metafunction", or if they are allowed to just write that metafunction
> explicitly and grab a beer.
> >
> > Well, yeah. Design patterns *are* obsolete in some more powerful
> > languages; instead of being recipes for implementing patterns in
> > various ways with various trade-offs, they're just code where those
> > trade-offs are customizations points of the algorithm. :)
> >
> > As a side note, some of us do this already, to the extent the language
> > limitations allow it. We had a particular policy in multiple places I
> > worked in, which was "never (try to) make your type a Singleton, use
> > ourcompany::Singleton<YourType>.
> > Also, please leave it up to the application programmer to decide how
> > many of YourTypes should exist in their program, and please never make
> > that decision for them." Various other oft-mentioned patterns are
> > feasible to implement with such a common library type/wrapper, but
> > reflection+injection opens quite some doors towards that ability. Like
> > Proxies and Mediators and Template Methods and Bridges etc.
> >
> >> I would thus argue the best source for generating examples is thus any
> design pattern textbook: try to write each one as a metafunction, and thus
> render knowledge of it obsolete altogether.
> >
> > It's certainly one source. The best, I don't know - things like
> > serialization and persistence are oft-mentioned examples of problems
> > where reflection/injection is a big help, but they aren't necessarily
> > well-represented in pattern books.
>
> Those sound great. Why not try writing one, using the new syntax?
>
> I think more of us be following Roland's example, trying to actually implement
> these things, and presenting the results to the list. It's a bit strange to be
> considering syntax changes without seeing it in action in large, real-world test
> cases.
>
> And as Roland found, trying to implement these real world cases often leads
> us to places the proposals have overlooked, thus identifying deeper issues.
>
> And beyond that, exchanging code instead of words would be a good way to
> lower the temperature in here and keep things in focus.
>
> But Roland can't be the only one.
>
> I think I've said my peace and presented a useful test case of my own so I'll
> bow out here and leave space for others, thanks all,
>
> Dave
>
> >
> >> FWIW, this belief is why I spent a year awhile back pretty much just
> learning clang and implementing the most general possible alternative to
> Andrew's, without much regard to syntax or cleanliness. The resulting ugly
> "glorified preprocessor"/string mixin approach is a standard by which I think
> Andrew's or any other alternative must be measured, and I will never be okay
> with any alternative that is not as capable as it, no matter how many people I
> admire and respect line up on the other side.
> >>
> >> But I would still very much welcome *improvements* on it that don't
> sacrifice its capabilities - it is definitely not without its problems; e.g. recall
> Richard's line that "a good metaprogram is semantic" - if indeed the
> "semantic" approach could be accomplished without losing the capabilities of
> the "syntactic" metaprogramming approach, I agree it is a big improvement,
> and thus Andrew's endeavor to develop such a semantic approach is certainly
> worthwhile, though incomplete at this point.
> >>
> >> The challenge Andrew et al will face, it seems to me, is that, to implement
> injection properly in things like Sum<T,U> and PreCalcdSum<T,U> and other
> still more complex examples, you really just need to be able to write multiple
> statements in "meta" space, complete with meta variable declarations,
> control flow statements, etc. - *in the midst of writing arbitrary code *in
> "non-meta" space - i.e. in the midst of writing expressions, or initializers, or
> base classes.
> >
> > Well.. I do expect to be able to inject function definitions, but I do
> > expect to do that semantically, meaning that I inject code fragments
> > that have injections in them, as opposed to injecting strings.
>
> --
> SG7 mailing list
> SG7_at_[hidden]<mailto:SG7_at_[hidden]>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.is<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg7&data=04%7C01%7Chsutter%40microsoft.com%7C7d9768cfb6dd4e2b5d4808d8d6be4a2a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637495460100701888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=viB2O0nxZgLwmc8OXoXOSZl6UX71Ea34cMn6THvLBYA%3D&reserved=0>
> ocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg7&data=04%7C01%7Chsutter%4<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg7&data=04%7C01%7Chsutter%40microsoft.com%7C7d9768cfb6dd4e2b5d4808d8d6be4a2a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637495460100701888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=viB2O0nxZgLwmc8OXoXOSZl6UX71Ea34cMn6THvLBYA%3D&reserved=0>
> 0microsoft.com%7C7d9768cfb6dd4e2b5d4808d8d6be4a2a%7C72f988bf86f141<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg7&data=04%7C01%7Chsutter%40microsoft.com%7C7d9768cfb6dd4e2b5d4808d8d6be4a2a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637495460100701888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=viB2O0nxZgLwmc8OXoXOSZl6UX71Ea34cMn6THvLBYA%3D&reserved=0>
> af91ab2d7cd011db47%7C1%7C0%7C637495460100701888%7CUnknown%7CT<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg7&data=04%7C01%7Chsutter%40microsoft.com%7C7d9768cfb6dd4e2b5d4808d8d6be4a2a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637495460100701888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=viB2O0nxZgLwmc8OXoXOSZl6UX71Ea34cMn6THvLBYA%3D&reserved=0>
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg7&data=04%7C01%7Chsutter%40microsoft.com%7C7d9768cfb6dd4e2b5d4808d8d6be4a2a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637495460100701888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=viB2O0nxZgLwmc8OXoXOSZl6UX71Ea34cMn6THvLBYA%3D&reserved=0>
> VCI6Mn0%3D%7C1000&sdata=viB2O0nxZgLwmc8OXoXOSZl6UX71Ea34cM<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg7&data=04%7C01%7Chsutter%40microsoft.com%7C7d9768cfb6dd4e2b5d4808d8d6be4a2a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637495460100701888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=viB2O0nxZgLwmc8OXoXOSZl6UX71Ea34cMn6THvLBYA%3D&reserved=0>
> n6THvLBYA%3D&reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg7&data=04%7C01%7Chsutter%40microsoft.com%7C7d9768cfb6dd4e2b5d4808d8d6be4a2a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637495460100701888%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=viB2O0nxZgLwmc8OXoXOSZl6UX71Ea34cMn6THvLBYA%3D&reserved=0>
Received on 2021-02-21 18:27:59