Re: [boost] [function types] New tag type logic [update]

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-06-30 22:36:01

From: Tobias Schwinger <tschwinger_at_[hidden]>
> Rob Stewart wrote:
> > From: Tobias Schwinger <tschwinger_at_[hidden]>
> >>Rob Stewart wrote:
> >>>From: Tobias Schwinger <tschwinger_at_[hidden]>
> >>>
> > Anyway, as you say, "variations" are semantic, not syntactic
> > elements.  Thus, they aren't concrete by definition, right?  The
> 
> "Concrete" as opposed to "abstract" ?

Yes.

> No, "variation" does not imply abstract or nonabstract.

Then it isn't semantic, right?

> > groups covered by a single tag are just that -- groups or
> > combinations of tags.  
> 
> The tags in the reference are all "aspect tags":
> One for each "variation" of each "aspect" there is.

Some represent groups of variations, right?

> > Trying to give that a name seems misguided
> 
> Why?

Because there are lots of new terms already, and it isn't always
necessary to give everything a name to discuss it.

> > unless it is a compound name like "variation set."
> 
> I like this one:
> 
>     When classifying types it is often necessary to match against
>     several variations of one aspect.  Special, *abstract*
>     variations make this possible.
> 
> (taken from your recent post)

We're making progress, however slow.

> >>>I think, like John suggested, that "composite tags" works better
> >>>than "abstract tags."  The special variation you use represents a
> >>>grouping or union of variations, not a generalization of them.
> >>
> >>I'm afraid it /is/ in fact a generalization - see 
> >>http://lists.boost.org/boost/2005/06/29472.php
> > 
> > In that message, even you said you weren't convinced.  I disagree
> 
> Yeah. That is not convinced that changing it is a good idea ;-).
> 
> > with your analysis for the reasons stated.  "Unspecified
> > decoration" is not an abstraction or generalization of
> 
> It sure is!

Well, I definitely disagree.

>     >>Considered apart from concrete existence: an abstract concept.<<
> 
> It can be considered apart from concrete existence. And it is an abstract concept 
> (within one aspect).

The same can be said for all of the tags.  None are concrete.
They have no physical form.

> It reads nicer using your "any" term, so let's use it here:
> 
>   "Reference-decoration" is also an "any-decoration".
>   "Any-decoration" is a generalization of "reference-decoration".

No.  "Any-decoration" *includes* or *contains*
"reference-decoration."  It is not a generalization of it.

> The aspects variations in a tag are not identical, just like a pointer type to an 
> abstract base and a pointer type to a concrete class are not identical.
> 
> Modeling each aspect with polymorphic classes, abstract variations would be 
> abstract classes with the matches they bundle derived from them.
> 
> For me it fits (almost) perfectly. However, I'm not pedantic about it -- and if it 
> really causes confusion I should probably change it; I'ld very much like to 
> retrace your lines of thinking before doing this (and I'm currently having some 
> difficulties with this), though.

A base class pointer is not a more abstracted version of a
derived class pointer.  They are both pointers.  What is more and
less abstract are the classes.

In the same way, one variation is not more abstract than another.

> >>     function_type< mpl::single_view<int>, unspecified_call >::type
> >>
> >>== "give me a function type of the default calling convention (the one you get 
> >>when you /don't specify/ it)"
> >>
> >>     function_type< mpl::single_view<int>, any_call >::type
> >>
> >>== <just strange>
> >>
> > Your version says, "Give me a function type of whatever calling
> > convention you like, I don't care which one you choose," to me.
> 
> No. In this context it means: don't tell the type system an explicit calling 
> convention (the reference already states this).

I know that's what you claim it "says."  I was telling you what
it means to me when I read it.

> Same goes for cv-qualification, for example:
> 
>     "unspecified_constness"
> 
> in synthesis context means:
> 
>     "I don't want to specifiy the constness *here* - use the qualfication of
>      the class type to determine it"
> 
> and *not*:
> 
>     "I don't care about the constness"

Then the constness is specified in that case.  It is specified as
that of the class type.  Therefore, you need something other than
"unspecified_constness" to express that.

> Generalizing this the subtle difference:
> 
>     "Give me whatever this means in this context, I won't specify it here"
> 
> instead of
> 
>     "I don't care"

You can state that's what it means, but that's now what it means
when one reads the code in ignorance.  That is, consider the
maintainer not familiar with the library.  What does
"unspecified" mean?

> >>If no second template argument is given, is_function asks for a "function type"; 
> >>that is as defined by the standard, "undecorated":
> >>
> >>     template<typename T, typename Tag = undecorated> struct is_function;
> >>
> >>Well, technically I could've used some "null tag" here, but it's more expressive 
> >>to say what we want, isn't it?
> 
> Sorry! ^^^^^ This is a very bad place for this sentence. I meant something 
> different from what it reads like: I could have used a "null tag" _in_the_example_ 
> (*not* for prototyping the metafunction).
> 
> > That says you want to know if T is an undecorated function
> > (whatever that is), not one with any of the recognized
> 
> The default arguments for the metafunctions are consistent with standard terms. 
> is_function in particular is also consistent with Boost.TypeTraits.

If you say so.  It still doesn't read well.

> > decorations.  A "dont_care," "unused," or similar tag would say
> > what you suggested it says now.
> 
> To fully understand what I meant with the "null tag" sentence above I have to 
> explain what "(default)" in the reference means:
> 
>      The semantics for unset aspects within a tag is equivalent to the one
>      of the combination of all aspect tags marked with "(default)" (in the
>      reference section) for these aspects, but with the exception that unset
>      aspects cannot override set aspects in the context of tag combination.

There's another paragraph that needs work!  Nevertheless, this
has no bearing on readability, which is what I'm trying to
address.

> > I was using that as an example because it was before me at the
> > time.  You're right that free functions and static member
> > functions have the same function type, so this works as written.
> > I was actually thinking about the examples I've seen in which you
> > use the "unspecified" tags to pick up a default.  I'm sorry I
> > confused things.
> 
> This is the same subtle issue as with the "unspecified" vs. "any" kind of thing, I 
> guess...

Yes.

> > As to your point that "free_or_static" is better than
> > "undecorated" in this case.  I disagree.  They are at least
> > equivalent, and having one less tag to remember is better.  After
> 
> In practice the one is absolutely neccessary and the other one /very/ useful in 
> the context of classification.

A good name may handle both with aplomb.  If not, one might be
only be applicable in one context, another in the other context.

> For synthesis you can pick the one you like best. This is so,  because there are 
> no illegal tags in any context this way.

It still means there are multiple, interchangeable tags.

> > all, your library will have to choose one to report as part of a
> > type's kind, so a client might not choose to use the one the
> > library chooses, so that client will need to know both.
> 
> Considering classification is a much more common use case than synthesis, the 
> client most likely needs to know both, anyway.
> 
> However if it's only about synthesis - the client only has to know one.
> 
> I'm not sure I understand what you mean, here. Can you perhaps try to explain it 
> differently?

You say a client needs to know both anyway.  That's only true if
both are available.  You say the client only needs to know one if
doing synthesis.  I don't think it's clear at this point how
common it will be for clients to only do synthesis with the
library, so making a case on that basis is a straw man at best.

> I tried to transform it and ended up with rewriting the whole sentence:
> 
>     When a tag is created from a type, it completely describes all aspects
>     of this type, so their variations are never abstract.
> 
> Feels smooth to me. Does it work?

Not quite.  Maybe this will do:

   A tag created from a type, it completely describes all of the
   aspects of the type.  The aspect variations in the tag are
   never abstract.

Note that I left "abstract" in only because you used it and
aren't convinced to do otherwise.  I don't think it is
appropriate.

> > result of the changes.  Here's another stab that might be more
> > accurate, and is certainly more succinct:
> > 
> >    The tags in a type's kind are explicit, not abstract.
> 
>           ^^^^
> You meant aspects here, I guess. Except this, in itself it's quite nice.
> 
> The problem is that I never was too happy with that "explicit" in the original and 
> here the problem becomes even more obvious: it would need a full defintion.

I'm not sure it should use "abstract" either.  At this point,
however, I'm lost as to what should or shouldn't be abstract.
Perhaps it would be good to put everything together and provide
larger, in context, extracts to consider in toto.

> >    When using the tag metafunction to combine tags, it is
> >    possible to have tags representing different variations of the
> >    same aspect in the same list.  When that occurs, the last
> >    variation is used; the others are ignored.
> 
> An adjustment is needed because of your previous s/combined/combined using the tag 
> metafunction/-suggestion, so "tag metafunction" does not repeat.

I don't understand where the repetition is/will be.

> "Same list" reads a little strange to me. It can be fixed easily by using 
> "template argument list of 'tag'" instead.

I didn't like it a lot either.  How about "tag's template
argument list" instead and I think it will be fine.

> We are talking about combination of tags anyway, so we might want to drop "when 
> combining tags" as well.

Probably so.

> While we're at stripping it down, I don't think it's important to explicitly say 
> that it is possible and that other aspects are ignored.
> 
> How about:
> 
>      When there are tags representing different variations of the same aspect
>      in the template argument list of 'tag', the last variation is used.

Hmmm.  I suppose you're right about the "it is possible" part,
but I think the "ignored" part is helpful.

   When there are tags representing different variations of the
   same aspect in tag's template argument list, the last
   variation is used; the others are ignored.

> Or maybe: s/is used/is dominant/

No.

> Btw. I don't think it is neccessary to spell this out in more detail. There should 
> be another more complex example, though.

OK.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;