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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-06-30 12:02:26

Tobias Schwinger wrote:
> 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".
> 
> 
>>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)?
> 
> - cv-qualification of member function pointers
> - the calling convention attribute
> 
> 
>>
>>>   described by *tag* types.
>>
>>
>>No paragraph break here.
> 
> 
> OK - but why?
> 
> 
>>
>>>   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...
> 
> 
>>
>>>   Tags which only encapsulate variations of a single aspect are called
>>
>>
>>s/only encapsulate/represent the/ ?
> 
> 
> OK.
> 
> 
>>
>>>   *aspect tags* in the following text (see reference).
>>
>>
>>Strike "in the following text."  You're creating the term for the
>>library, not just the following text.
> 
> 
> OK.
> 
> 
>>
>>>   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"?
> 

Bad. But how about:

     Aspect tags can be used to query one particular aspect of the 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.
> 
> 
>>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
> 
> 
>>>        is_function< T, free_or_static >
>>>
>>>     The free_or_static describes an abstract variation of the decoration aspect
>>
>>                          ^tag
>>
>>
>>
>>>     and makes the above code is equivalent to:
>>
>>
>>s/is //
>>
> 
> 
> OK.
> 
> 
>>>        mpl::or_< is_function_type< T, undecorated>
>>>                , is_function_type< T, pointer>
>>>                , is_function_type< T, reference> >
>>>
>>>   An important use case for abstract variations is to match any variation of an
>>>   aspect; that is, to ignore it in the context of type classification. Because of
>>>   this, every aspect has at least one abstact variation, described by the
>>
>>
>>s/abstact variation/abstract tag/ (or "composite tag" ;0)
>>
> 
> 
> Noted. Not sure, yet.
> 
> 
>>>   (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.
> 
> 
>>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?
> 
> 
> But this is not the only issue I had with that one of your versions (note btw. 
> that the current version is also heavily inspired by a different one from you):
> 
>       typedef tag< some_query, unspecified_decoration > new_query;
>       // widens a query but doesn't test anything
> 
> 
>>>   Each abstract variation of an aspect has a non-abstract semantical equivalence
>>
>>
>>s/semantical/semantic/
> 
> 
> Whoops - this one crept in again...
> 
> 
>>I like the "non-abstract semantic equivalence" phrasing to
>>explain the "concrete" usage of the tags.
>>
>>
>>
>>>   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 know the "(default)" in the reference section is still very confusing. Please 
> just ignore it, for now (it refers to the default of unset aspects *in a tag*, 
> *not* to the template default arguments of the metafunctions).
> 
> 
>>>   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.
> 
> 
>>
>>>        signature< void() >
>>>ANNOTATION: ^^^ will be a model of Tag (this is not yet documented)
>>>        // describes all aspects: undecorated, non-variadic, ...
>>>
>>>   When classifying and especially when synthesising types, there are situations
>>>   where it is neccessary to describe more than one aspect. Therefore tags can be
>>
>>
>>s/where/in which/ (situations aren't places)
>>
> 
> 
> OK.
> 
> 
>>>   combined.
>>
>>
>>   combined in a single query using the tag metafunction.
> 
> 
> OK. But s/in a single query// -- combination of tags does not imply querying.
> 
> 
>>
>>>   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.
> 
> 
>>>        function_type< mpl::vector<int,int>, tag<pointer,variadic> >::type
>>>
>>>   In classification context all aspects in the query tag must match:
>>
>>
>>s/context/contexts/
> 
> 
> OK.
> 
> 
>>
>>>        is_function_type< void(...), tag<free_or_static,variadic> >::value
>>>        // is true
>>>
>>>        is_function_type< void(X::*)(...), tag<free_or_static,variadic> >::value
>>>        // is false
>>>
>>>   When the 'tag' metafunction is used to combine tags, which describe different
>>
>>
>>No comma.
>>
> 
> 
> OK.
> 
> 
>>>   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...
> 
> What is wrong with the original in your opinion??
> 
> 
> 
>>   is used; the others are ignored.
>>
>>
>>
>>>        tag<free_or_static,reference>
>>>        // decoration aspect is 'reference'
>>>
>>>        tag<reference,undecorated>
>>>        // decoration aspect is 'undecorated'
>>>
>>>        tag<undecorated,reference,undecorated>
>>>        // decoration aspect is 'undecorated'
>>>
>>>   Tag combination occurs either explicitly by using the 'tag' metafunction or
>>>   implicitly when using 'function_type' with an optionally decorated function
>>>   type or a tag as its first template argument:
>>
>>
>>   Tag combination occurs either explicitly, by using the tag
>>   metafunction, or implicitly.  Implicit tag combination occurs
>>   when using function_type with a tag or a (possibly decorated)
>>   function type as its first template argument.
> 
> 
> OK. Better.
> 
> <snip reference>
> 
> 
> There's lots of valuable material in your post.
> 
> 
> Thank you,
> 
> Tobias
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>