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

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2005-07-01 05:44:56

Rob Stewart wrote:
> 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?
> 

Can't see why it should imply this.

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

Well, not exactly. Some _match_ groups of (other) variations (in an appropriate 
context) *but* _represent_, well, /abstract/ concepts that include them.

The "groups" you are talking about _are_ in fact _single_ variations of _single_ 
aspect tags.

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

"Aspect" and "variation" are proper English words, aren't they? Set into context 
by the preceding text.

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

<snip>

-> what's wrong with "abstract?" <-

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

It does not *include* or *contain* anything (see above). It represents an 
abstraction; because of this it _matches_ "reference-decoration". In different 
context there is an "automatic concretization" (for which to document I need the 
term).

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

That's what I just said! Here's the analogy:

     Class type             O--O Aspect variation
     Pointer/Class instance O--O Aspect encoded in a Tag

Assuming special_aspect derived from (abstract base) aspect:

     // distinct at type level
     is_same<aspect*,special_aspect*>::value == false

     // "match" in the context of pointer assignment
     aspect* a1 = new special_aspect;

     // "automatic concretization" in a generic factory
     typedef typename mpl::eval_if< is_abstract<T> 

                                  , concretize<T>
                                  , mpl::identity<T> >::type concrete_aspect;
     aspect* a2 = new aspect_type;

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

But they are (see above) ;-) -- this is why I don't want to call it any other way.

<snip>

-> "any" vs. "unspecified" <-

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

He's gotta take a look in the documentation to see what it means instead of 
jumping to false conclusions!

I don't believe it's always possible to make everything immediately obvious to an 
ignorant reader at the level of source code. If it would, we would not need 
documentation at all, would we?

It's your imaginary library's author's responsibility to keep his code clean and 
optimal names also depend on the context the library is used in (not only how the 
tags are used with the library). Tags are just types -- typedef at will!

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

A peliminary attempt - it's not in, yet...

<snip>

-> "automatic conretization" <-

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

I don't think swamping the interface with aliases is a good idea. If the names 
provided by the library do not make sense in any particular case, create an alias 
for your case using 'typedef'.

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

No. There no interchangable tags!

There are some with similar semantics in the particular context of type synthesis 
(for the sake of a consistent logic and a very efficient implementation - not to 
give a toy to the user, see below).

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

Let's be more precise: a client who fully wants to understand the logic.

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

But: the "whether or not to automatically concretize during synthesis" discussion 
is absolutely pointless:

I am documenting it because it is defined behviour which is fundamental for the 
whole logic to work. Simple cases like this one:

     function_type< mpl::vector<int,int>, pointer >::type // == int(*)(int)

would not work without it.

I'm trying (obviously still without much success) to give the user chance to fully 
understand that logic.

The examples only illustrate how things behave -- they do not recommend use cases!
I should probably make this more obvious... Any ideas?

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

The first sentence seems to be invalid due to restructuring artefacts.

And a flaw crept in earlier: A tag does not describe the subtypes of a type, only 
its kind

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

Did we have this version, already?

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

Using the "runtime polymorphism analogy" again "creating a tag from a type" is in 
some ways similar to the behaviour of RTTI for polymorphic types: You get a 
type_info object describing the most derived type.

I'll apply your suggestions and post a new revision of the complete draft after 
this message.

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

Never mind!

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

I like this.

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

Thanks,

Tobias