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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-07-03 15:08:57

From: Tobias Schwinger <tschwinger_at_[hidden]>
> 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.

Let's forget about this.  I don't think it helps us with the rest
of the discussion anyway.

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

In that sense, they do represent groups of variations.  That is,
"any_decoration" covers "reference_decoration" and the others.  I
don't mean that it is a bit pattern that includes the bits from
the others, just that when you match reference_decoration, you
can also match any_decoration.

Having said that, however, it is not true that
reference_decoration is a specialization of any_decoration.
Instead, it's like color and red.  Red is not a specialization of
color; it's an instance or example of color.  You could model
this with a class called Color and one called Red, but you'd be
much more likely to have Red be an instance of Color.  If you
then have an "any color" object, you would probably model that
with a special Color instance, not with a base class for the
normal colors.  Thus, Red isn't a specialization of "any color"
but just another Color.

The special behavior of "any color" comes from how the library
treats that instance.  Since the library treats "any color" as
matching any other Color, it can be thought of as containing--or
at least representing--all of the other Colors.

Similarly, reference_decoration and any_decoration are instances
of decoration, and reference_decoration is not a specialization
of any_decoration.

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

Are we talking about the same thing?  Yes, any_decoration is a
single variation of the decoration aspect tag, but it represents
all of the other variations.  It is treated as a composite of the
other variations.

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

It isn't that they are improper words or that they can't be set
in context.  It is that the cognitive effort needed to learn the
vocabulary of the library can be more complicated than
understanding the library itself.  Just discussing the behavior
and syntax may be sufficient in many cases.  Creating a term for
something can complicate matters.

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

Precisely what I've been saying all along.  It implies a
generalization/specialization relationship that I don't see.

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

At this point, it seems we're in the middle of an "is not," "is
too" argument.

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

I think I've addressed that above.  Furthermore, consider that
you can't use a reference_decoration anywhere you can use an
any_decoration, unless I'm sorely mistaken.

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

I'm not sure it causes too much confusion, but I don't think it's
the right analogy, so it doesn't help to clarify things.
Composition seems right on target.

Have I've helped you understand my thinking with this message?

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

I don't see it.  A base class pointer can be used for both
types.  A derived class pointer can be used for only one.  A
reference_decoration can't be used where you need an
any_decoration, so I don't think they fit well.  Perhaps I'm just
blind or dense.

> 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;
                        ^^^^^^^^^^^
concrete_aspect?

I don't know what concretize<T> does, but I'm guessing you mean
that this metaprogram magically produces special_aspect if T
actually points to a special_aspect, so that concrete_aspect is
special_aspect either way.

I understand how you're trying to make the analogy between tags
and pointers, but I don't see the analogy.

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

That should be the goal.  You can't always achieve it, but here I
think you can.

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

I disagree with the onus for clarity in this case.

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

I wasn't clear, but I meant make it so that they would only work
in one context or the other.  Then the names don't have to work
for both contexts and can be made plain for the context to which
they apply.

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

Fine.  I'm lost then and I'm sorry to say I can't spend much more
time on this.

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

Not now.  I'm sorry.

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

Oops!  You're right.

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

OK.

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

I don't recall, but there should be no comma.

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