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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-06-30 18:15:05

Rob Stewart wrote:
> From: Tobias Schwinger <tschwinger_at_[hidden]>
> 
>>Rob Stewart wrote:
>>
>>>From: Tobias Schwinger <tschwinger_at_[hidden]>
>>>
>>>>   Tag types:
>>>>   ----------
>>>>
>>>>   The kinds of a type to be synthesised and complex classification queries are
>>
>>Here's a typo: it should be either "kinds of types" or "kind of a type".
> 
> 
> Based upon your explanation below, it's the latter.
> 
> 
>>>I don't understand "the kinds of a type."  Is this a reference to
>>>something discussed elsewhere? 
>>
>>"Elsewhere" is work in progress ;-). Here's a (maybe still bad) defintion:
>>
>>A type supported by this library is completely described by its subtypes and its 
>>kind. The kind collectively refers to the following information:
>>- decoration (none,pointer,reference,member pointer)
>>- variadicity
>>   ^^^^^^^^^^^
>>ANNOTATION: is this a word? Is it "variadicness" (sounds even stranger)?
> 
> 
> Well, I don't find "variadic" in my dictionary.  My guess is that
> word was coined, so if you need a noun form of "variadic," you'd
> have to invent that, too.  OTOH, you could rephrase:
> 

"Variadic" seems to be a term specific to programming - here are the results of a 
Wikipedia search for it, for example:

   http://en.wikipedia.org/wiki/Variadic_function
   http://en.wikipedia.org/wiki/Variadic_macro
   http://en.wikipedia.org/wiki/C_programming_language
   http://en.wikipedia.org/wiki/Empty_product
   http://en.wikipedia.org/wiki/Name_mangling
   http://en.wikipedia.org/wiki/C_Plus_Plus

>    - whether the function is variadic
> 

OK. This is better.

> 
>>- cv-qualification of member function pointers
>>- the calling convention attribute
> 
> 
> Excellent.  Now I understand.  With a link from "kind of type" to
> this description, it should work fine.
> 
> 
>>>>   described by *tag* types.
>>>
>>>No paragraph break here.
>>
>>OK - but why?
> 
> 
> A paragraph is to be a cohesive set of sentences that posit and
> support a thesis.  A proper paragraph is rarely a single
> sentence, though it certainly can be.  In this case, the
> separated sentence simply amplifies on the information of those
> in the previous paragraph.
> 

Makes sense.

> 
>>>>   A tag encapsulates one or more aspects of the kind of type.
>>>
>>>s/kind/kinds/ to be consistent with the first sentence?  (I still
>>>don't understand the phrase, though.)
>>
>>Caused by that &#^$% typo above, I guess...
> 
> 
>    A tag encapsulates one or more aspects of a type's kind.
> 
> 
>>>>   Aspect tags can be used to query, whether a type's kind reflects this aspect:
>>>
>>>No comma.  s/reflects/includes/ or s/reflects/is described by/ ?
>>
>>OK. How about "contains"?
> 
> 
> That's fine, but I think "includes" works a bit better--it
> doesn't conjure up container semantics to me.
> 

I changed it to a simpler form:

    Aspect tags can be used to query one particular aspect of a type's kind.

> 
>>>>        is_function< T, variadic >
>>>>        is_function< T, pointer >  // same as is_function_pointer<T>
>>>>
>>>>   When classifying types it is often necessary to match against several
>>>>   variations of one aspect. There are special variations which make this
>>>>   possible. These are called *abstract variations*.
>>>
>>>   There are special tags that represent groups--or the union--of
>>>   several variations of a single aspect.
>>>
>>>Shouldn't "abstract variations" be "abstract tags?"
>>
>>Don't think so: "aspects" and "variations" are semantics, the tags are their 
>>syntactical encapsulation.
> 
> 
> Here you go again!  I looked it up and was surprised to find that
> "syntactical" is a recognized variant of "syntactic." ;-)
> Nevertheless, I suggest "syntactic" rather than "syntactical."

The dictionaries seem to list these versions to make things easier for people with 
a non-native English like me ;-).

> 
> Anyway, as you say, "variations" are semantic, not syntactic
> elements.  Thus, they aren't concrete by definition, right?  The

"Concrete" as opposed to "abstract" ?
No, "variation" does not imply abstract or nonabstract.

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

> Trying to give that a name seems misguided

Why?

> 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)

> 
>>>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!

    >>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).

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".

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.

> 
>>>>   (aspect) tag named "unspecified_" plus the aspect name.
>>>
>>>Instead of "unspecified_" how about "any_?"  It is shorter and
>>>fits the prose.  Whenever you discuss this, you refer to matching
>>>*any* variation.
>>>
>>>
>>>>        is_function< T, unspecified_decoration >::value
>>>>        // true for any type T the library can handle
>>
>>Not sure here:
>>
>>     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>
>>
>>I do like the shortening, though.
> 
> 
> 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).

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"

> So does mine.  However, I raised that as an issue elsewhere
> anyway.
> 

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 said my version was incorrect because I suggested this query
>>>was only useful in combination with other queries.  I don't see
>>>the point in asking whether a type fits any variation of an
>>>aspect while asking about no other aspects.  In that case, you're
>>>asking about no aspects.  The above suggests that one might have
>>>to choose an "any" aspect tag just to ask whether a type is a
>>>function type, but that just seems messy. So, what are the use
>>>cases for a query like the above in which nothing specific is
>>>queried?
>>>
>>
>>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.

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

> 
> 
>>>>   when used in the context of type synthesis (as defined in the reference
>>>>   section):
>>>>
>>>>        function_type<void(X::*)(), free_or_static>::type
>>>>
>>>>     is equivalent to:
>>>>
>>>>        function_type<void(X::*)(), undecorated>::type
>>>
>>>That use of free_or_static seems just plain wrong.  Why would you
>>>synthesize a type while giving a choice as to how it is
>>>decorated?  Yes, you can document that free_or_static and
>>>undecorated are the same in this context, but it is confusing at
>>>best.
>>
>>Imagine this case:
>>
>>   function< typename function_type<MemFnPtr, free_or_static>::type >
>>
>>I think it does make sense to express 'free_or_static' (== "remove the member 
>>pointer, please") instead of 'undecorated', here.
>>
>>It's not about giving a choice to the library how things are done but giving a 
>>choice to the user to differently express things in different contexts. Further 
>>fail-safeness has some advantages.
>>
>>Remember btw. that the "_or_" in the name "free_or_static" does not reflect 
>>technical distinction but only exists in terminology. That's why I initially used 
>>"unbound" instead of "free_or_static".
> 
> 
> 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...

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

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

> 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?

> 
> 
>>>>   When a tag is taken from a type, the resulting tag explicitly describes all
>>>>   aspects, none of them with an abstract variation:
>>>
>>>   When querying for a tag describing a type, the result is a
>>>   nonabstract tag that describes all aspects of the type.
>>
>>>Yours was structured poorly, but more importantly, I didn't get
>>>the "taking" a tag from a type part.  I'm sure mine doesn't
>>>capture the concept quite right, but hopefully it helps.
>>
>>Inspired by "taking the address of an object" -- but you're right -- there is a 
>>serious flaw: the tag is not a property of the type.
>>
>>Either s/tag/kind/ or s/taking/creating/ fixes it. I prefer the former.
> 
> 
> Only the former fits your text, and you didn't say whether you

;-) Noticed this, too. Haven't found the time to correct it, yet. Sorry, again.

> liked my version, so I'm not certain what you mean to be the

Well I find "when querying for a tag describing a type" isn't exactly perfect. It 
is correct, but can easily lead to confusion because "querying" is used in a 
different context in other places of the text.

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?

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

> 
> 
>>>>   E.g. for synthesising a both variadic and pointer-decorated function:
>>>
>>>FWIW, I always find it appropriate to follow "for example" with a
>>>comma, so I consider it approprite to follow "e.g." with one.
>>
>>OK. ... and probably spell it out. Looks nicer, I guess.
> 
> 
> You can spell it out if you like, but "e.g." is ubiquitous.
> 

I know it's alright -- "looks nicer" meant the typeface.

> 
>>>>   variations of the same aspect, the right hand side tag's variation is used --
>>>>   it *overrides* the aspect:
>>>
>>>Try this instead:
>>>
>>>   When using the tag metafunction to combine tags, it is
>>>   possible to have different variations of the same aspect in
>>>   the list.  In that situation, the last (rightmost) variation
>>
>>   ^^ "in the tags in the list" to be correct - note: syntax vs. semantics.
>>
>>After applying this correction I don't find it too appealing...
> 
> 
> I agree.  It's the wrong correction.  See below.
> 
> 
>>What is wrong with the original in your opinion??
> 
> 
> OK, here's your original:
> 
> 
>>>>   When the 'tag' metafunction is used to combine tags, which describe different
>>>>   variations of the same aspect, the right hand side tag's variation is used --
>>>>   it *overrides* the aspect:
> 
> 
> These are some things I don't like about it:
> 
> - passive voice ("is used to");
> - doesn't spell out the case for this situation as mine attempts;
> - there is no "right hand side tag" if the list is broken across
>   lines (I should have resisted the temptation to add "rightmost"
>   to my version, but I didn't);
> - uses "overrides" versus "ignored" which introduces an unneeded
>   term.
> 
> Here's another try:
> 
>    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.
> 

It's OK, but not perfect yet, IMO:

An adjustment is needed because of your previous s/combined/combined using the tag 
metafunction/-suggestion, so "tag metafunction" does not repeat.

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

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

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.

Or maybe: s/is used/is dominant/

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

Thanks,

Tobias