Date: Tue, 18 Jun 2019 15:08:23 -0400
On Tue, Jun 18, 2019 at 2:59 PM Hoemmen, Mark via SG14 <
sg14_at_[hidden]> wrote:
> [...]
>
> If we wanted to represent “Hermitian matrix” or “Triangular matrix” in our
> design, without writing a complicated data structure that the algorithms
> would never use anyway, we would have needed some way to “tag” a matrix
> with mathematical properties. For example:
>
>
>
> > Have you considered tag dispatching for algorithm overloads?
>
>
>
> We considered this idea. You can see a brief discussion at the end of
> P1673 (“Options and votes”). We actually want to bring it up for a vote.
>
>
>
> The “tag dispatching” approach calls for a way for users to add their own
> tags, since library can’t possibly cover all mathematical properties of
> interest. Thus, many (perhaps all) of the functions would need to be
> customization points. That would add a LOT of customization points to the
> Standard Library. LEWG and LWG probably won’t accept that without a strong
> argument.
>
Mark, have you considered first implementing this thing as a stand-alone
library, so that you can get some usage experience with it and see whether
the "tag dispatching" idea is a good one via user feedback?
That is, rather than let the software architecture be dictated by
*political* concerns ("what design is LWG most likely to accept"), I think
it would be better to drive it based on *technical* concerns ("what design
is most adoptable for actual programmers and does it satisfy their
performance needs"). You can't really do that without an implementation.
my $.02,
–Arthur
sg14_at_[hidden]> wrote:
> [...]
>
> If we wanted to represent “Hermitian matrix” or “Triangular matrix” in our
> design, without writing a complicated data structure that the algorithms
> would never use anyway, we would have needed some way to “tag” a matrix
> with mathematical properties. For example:
>
>
>
> > Have you considered tag dispatching for algorithm overloads?
>
>
>
> We considered this idea. You can see a brief discussion at the end of
> P1673 (“Options and votes”). We actually want to bring it up for a vote.
>
>
>
> The “tag dispatching” approach calls for a way for users to add their own
> tags, since library can’t possibly cover all mathematical properties of
> interest. Thus, many (perhaps all) of the functions would need to be
> customization points. That would add a LOT of customization points to the
> Standard Library. LEWG and LWG probably won’t accept that without a strong
> argument.
>
Mark, have you considered first implementing this thing as a stand-alone
library, so that you can get some usage experience with it and see whether
the "tag dispatching" idea is a good one via user feedback?
That is, rather than let the software architecture be dictated by
*political* concerns ("what design is LWG most likely to accept"), I think
it would be better to drive it based on *technical* concerns ("what design
is most adoptable for actual programmers and does it satisfy their
performance needs"). You can't really do that without an implementation.
my $.02,
–Arthur
Received on 2019-06-18 14:10:22