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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-07-01 22:21:03

From: David Abrahams <dave_at_[hidden]>
> Rob Stewart <stewart_at_[hidden]> writes:
> > From: David Abrahams <dave_at_[hidden]>
> >> Rob Stewart <stewart_at_[hidden]> writes:
> >> >
> >> >    When classifying types, it is often necessary to test for any
> >> >    one of several variations of an aspect.  A common case is
> >> >    ignoring an aspect which means to allow a match for any
> >> >    variation of that aspect 
> >> 
> >> No, way too twisty.  You just lost me.  Does the aspect mean "to
> >> allow...", or is it an "aspect that means (intends) to allow..." or is
> >> it "ignoring an aspect" that "means to allow...?"
> >
> > I don't see the problem.  Please suggest an alternative that you
> > don't find "way too twisty."
> 
> I don't have time to do that right now, and it's so ambiguous that I
> don't even know which of the 5 or 6 meanings I should represent.

That doesn't leave us much opportunity to make progress.

> >> Try to resist the temptation to pack all the meaning into one sentence.
> >
> > Neither quoted sentence seems long or complex.  Perhaps there
> > was something you snipped to which you were referring?
> 
> No.

Since you said it was the second sentence (below), and you
snipped part of it, then clearly it was to something you snipped
that you were referring.

> > Here's the full text of my suggestion:
> >
> >    When classifying types, it is often necessary to test for any
> >    one of several variations of an aspect.  A common case is
> >    ignoring an aspect which means to allow a match for any
> >    variation of that aspect and is only useful when also testing
> >    for other aspects.  Ignoring an aspect means using an
> >    "unspecified_*" tag.  For example, allowing a match for any
> >    decoration requires using the <tt>unspecified_decoration</tt>
> >    tag.
> >
> > Are you referring to the second sentence?  
> 
> Yes.
> 
> > I could split it at "and" forming two sentences:
> >
> >    A common case is ignoring an aspect which means to allow a
> >    match for any variation of that aspect.  That is only useful
> >    when also testing for other aspects.
> >
> > Is that what you wanted?  
> 
> No, all the same questions apply.  It can be read several different
> ways:
> 
>         (ignoring an aspect) which means (to allow a match for any
>         variation of that aspect.)
> 
> or
> 
>         ignoring (an aspect (which means to allow a match for any
>         variation of that aspect))
> 
> or
> 
>         ignoring (an aspect which means to allow a match)) for (any
>         variation of that aspect)
> 
> or...
> 
>         There really are many many more.  

If you say so.  I have to assume you're serious, but I really
can't imagine how it is you think all of those (and more)
variations are supported by the sentence in question.

> And you don't really mean to say that "A common case" is doing the
> ignoring, do you?

Yes.

> And there should be a comma before "which."

I'll grant that a comma there may be helpful, but it isn't
necessary.  Besides, I'm surprised to hear you call for a comma
given your recent remark about how comma happy folks have become.

The meaning is simple:

   - A common case is ignoring an aspect
   - Ignoring an aspect means to allow a match for any variation
     of that aspect

Does adding the comma fix the confusion for you?

   A common case is ignoring an aspect, which means to allow a
   match for any variation of that aspect.  That is only useful
   when also testing for other aspects.

> > I still find the original to be fine,
> 
> Of course you do; you wrote it.  It's still ambiguous in many ways.

That's not true.  I've noticed many problems with things I've
written whether others point it out or not.  When someone points
out something, I give due consideration and try to evaluate what
I've written as objectively as I can.

I'm trying to understand your problem but I'm having a tough time
doing so.

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