Re: [boost] [function types] New tag type logic
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> 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
Please excuse me for jumping into the middle of this discussion. I am only a budding metaprogrammer, so that influences how I read things like this, so bear with me. With this phrasing, it is unclear to me whether the common case is "ignoring an aspect" or if it is really "allowing a match for any variation of an aspect" which I can do by "ignoring an aspect."
Neither quoted sentence seems long or complex. Perhaps there was something you snipped to which 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.
In this paragraph, you are telling me that "ignoring an aspect" is "allow a match for any variation of that aspect" (sentence 2) and that "ignoring an aspect" is "using an "unspecified_*" tag" (sentence 3). The use of "means" in both sentences is awkward. It is also unclear that "allow a match for any variation of that aspect" is actually the same as "using an unspecified_* tag." I tend to be more conversational in my writing, but I would be tempted to write something like: When classifying types, it is often necessary to test for any one of several variations of an aspect. A common case is allowing a match for any variation of an aspect. This is done by ignoring that aspect and is implemented by using an "unspecified_*" tag. For example, to allow a match For any decoration would require using the <tt>unspecified_decoration</tt> tag. I just wanted to throw in my $.02. I'll go back into lurker mode now. :) Joe
Greer, Joe wrote:
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> 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
Please excuse me for jumping into the middle of this discussion. I am only a budding metaprogrammer, so that influences how I read things like this, so bear with me. With this phrasing,
I don't believe it's metaprogramming specific -- let's clear up the logic, first:
it is unclear to me whether the common case is "ignoring an aspect" or if it is really "allowing a match for any variation of an aspect"
Given a variable 'a' which can be either '1', '2' or '3' it doesn't make a difference: if ((a == 1) || (a == 2) || (a == 3)) // match any variation of a { // do something } is logically equivalent to // no if -- just ignore a { // do something }
which I can do by "ignoring an aspect."
Equivalence is commutative: You can ignore 'a' by allowing any variation and you can allow any variation by ignoring 'a' -- no difference, again. Making any difference would be talking about implementation details in a parapraph about plain logic.
Neither quoted sentence seems long or complex. Perhaps there was something you snipped to which 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.
I have the following problems with this: - it's too long - 80% focusses on a special case - it's not true that it only makes sense when testing for other aspects
In this paragraph, you are telling me that "ignoring an aspect" is "allow a match for any variation of that aspect" (sentence 2) and that "ignoring an aspect" is "using an "unspecified_*" tag" (sentence 3). The use of "means" in both sentences is awkward. It is also unclear that "allow a match for any variation of that aspect" is actually the same as "using an unspecified_* tag."
I tend to be more conversational in my writing, but I would be tempted to write something like:
When classifying types, it is often necessary to test for any one of several variations of an aspect. A common case is allowing a match for any variation of an aspect. This is done by ignoring that aspect and is implemented by using an "unspecified_*" tag. For example, to allow a match For any decoration would require using the <tt>unspecified_decoration</tt> tag.
This one suffers similar problems:
I just wanted to throw in my $.02. I'll go back into lurker mode now. :)
OK, here is my current top-candidate: 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*. The most important case is to match any variation; that is, to ignore that aspect in the context of type classification. Because of this, every aspect has at least one abstract variation named "unspecified_" plus the aspect name.
Sorry! I accidently hit the send button, please ignore this post.
OK, here is my current top-candidate:
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*.
The most important case is to match any variation; that is, to ignore that aspect in the context of type classification. Because of this, every aspect has at least one abstract variation named "unspecified_" plus the aspect name.
That one also makes sense to me, I'm still not sure that "abstract" is the right word though :-) Explanation: to me if something is "abstract" then you need to add something to it, extend it in some way to make it concrete. What you're doing is combining several concrete definitions to form a non-specific union of some kind. So a quick trip to thesaurus.com suggests: "composite", "compound" or "mixed" as possible names, do any of these work for you? John.
John Maddock wrote:
OK, here is my current top-candidate:
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*.
The most important case is to match any variation; that is, to ignore that aspect in the context of type classification. Because of this, every aspect has at least one abstract variation named "unspecified_" plus the aspect name.
;-( - I knew this would happen... I accidently hit the "Send"-button before the post was finished...
That one also makes sense to me, I'm still not sure that "abstract" is the right word though :-)
Explanation: to me if something is "abstract" then you need to add something to it, extend it in some way to make it concrete. What you're doing is
Interesting... This is exactly why I came up with this term in the first place: An abstract variation of an aspect does not concretely describe the aspect of the kind of type. It describes it, well, in an /abstract/ way: Looking at classification, analog to pointer declaration, we constrain a (kind of) type by specifying a special (kind of) type that only describes a category (but nothing concrete). Type synthesis is in some ways similar to a constructor call: actually we can't create an "unspecified decorated" function type - we can only create an undecorated or (member-)pointer-decorated or reference-decorated function type. So there /is/ the kind of extension you describe, although implicitly done by a default mechanism. "Abstract" let's the user intuitively suspect something like an "external tree structure" (i.e. only leafes carry user data), that's why I like it.
combining several concrete definitions to form a non-specific union of some kind. So a quick trip to thesaurus.com suggests: "composite", "compound" or "mixed" as possible names, do any of these work for you?
I'm not convinced, yet. Maybe I'm having difficulties to fully understand you. Can you perhaps try to clarify what makes "abstract" unsuitable in your opinion? Thanks, Tobias
Tobias Schwinger wrote:
John Maddock wrote:
OK, here is my current top-candidate:
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*.
The most important case is to match any variation; that is, to ignore that aspect in the context of type classification. Because of this, every aspect has at least one abstract variation named "unspecified_" plus the aspect name.
;-( - I knew this would happen... I accidently hit the "Send"-button before the post was finished...
That one also makes sense to me, I'm still not sure that "abstract" is the right word though :-)
Explanation: to me if something is "abstract" then you need to add something to it, extend it in some way to make it concrete. What you're doing is
Interesting... This is exactly why I came up with this term in the first place:
An abstract variation of an aspect does not concretely describe the aspect of the kind of type. It describes it, well, in an /abstract/ way:
Looking at classification, analog to pointer declaration, we constrain a (kind of) type by specifying a special (kind of) type that only describes a category (but nothing concrete).
Type synthesis is in some ways similar to a constructor call: actually we can't create an "unspecified decorated" function type - we can only create an undecorated or (member-)pointer-decorated or reference-decorated function type. So there /is/ the kind of extension you describe, although implicitly done by a default mechanism.
^^^^^^^^^^^^^^^^^^^^ and it is still helpful to give the user an idea how this works, in order to explain this mechanism.
"Abstract" let's the user intuitively suspect something like an "external tree structure" (i.e. only leafes carry user data), that's why I like it.
s/let's/lets/
combining several concrete definitions to form a non-specific union of some kind. So a quick trip to thesaurus.com suggests: "composite", "compound" or "mixed" as possible names, do any of these work for you?
I'm not convinced, yet. Maybe I'm having difficulties to fully understand you. Can you perhaps try to clarify what makes "abstract" unsuitable in your opinion?
Thanks,
Tobias
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I'm not convinced, yet. Maybe I'm having difficulties to fully understand you. Can you perhaps try to clarify what makes "abstract" unsuitable in your opinion?
Well in C++ at least abstract has a specific meaning, and from Webster's we get: "Considered apart from concrete existence: an abstract concept. " What we have here in this case is a union of several concrete concepts, it's more like a wildcard really: "match a or b or c". That's the logic anyway, but as I said before I'm not sure how much it really helps. John.
John Maddock wrote:
I'm not convinced, yet. Maybe I'm having difficulties to fully understand you. Can you perhaps try to clarify what makes "abstract" unsuitable in your opinion?
Well in C++ at least abstract has a specific meaning,
Excuse my blunt question: did you read the part of my previous post about the analogy with abstract classes? ( In fact, I was very much looking forward to read your comments on this :-) ).
and from Webster's we get:
"Considered apart from concrete existence: an abstract concept. "
A category for one possibilty of a mutually exclusive group of variations (with a similar /abstract concept/, for that matter) /is/ apart from /concrete existence/, isn't it?
What we have here in this case is a union of several concrete concepts, it's more like a wildcard really: "match a or b or c".
The reason to have a term for it at all is /not/ to document the match -- it's to document the synthesis behaviour. I've nothing against changing that term, however, "abstract" still cuts it best and even the definition from Webster's seems to fit nicely IMO. Btw. a "named wildcard that represents a category of variations with a similar (abstract) concept" matches the above defintion as well, doesn't it? I still don't get what's wrong with the "abstract" term, I guess... Sorry, Tobias
Well in C++ at least abstract has a specific meaning,
Excuse my blunt question: did you read the part of my previous post about the analogy with abstract classes?
Yes, but I don't think I understood your argument, sorry.
I've nothing against changing that term, however, "abstract" still cuts it best and even the definition from Webster's seems to fit nicely IMO.
Btw. a "named wildcard that represents a category of variations with a similar (abstract) concept" matches the above defintion as well, doesn't it?
I still don't get what's wrong with the "abstract" term, I guess...
The term we use here is less important than most of the other comments that Rob and others have come up with, so if you're set on it, lets go with that until or unless someone comes up with a killer alternative. John.
Tobias Schwinger <tschwinger@neoscientists.org> writes:
I don't believe it's metaprogramming specific -- let's clear up the logic, first:
it is unclear to me whether the common case is "ignoring an aspect" or if it is really "allowing a match for any variation of an aspect"
Given a variable 'a' which can be either '1', '2' or '3' it doesn't make a difference:
if ((a == 1) || (a == 2) || (a == 3)) // match any variation of a { // do something }
is logically equivalent to
// no if -- just ignore a { // do something }
which I can do by "ignoring an aspect."
Equivalence is commutative:
You can ignore 'a' by allowing any variation and you can allow any variation by ignoring 'a' -- no difference, again.
Making any difference would be talking about implementation details in a parapraph about plain logic.
Isn't this a complicated way of saying something simple? Is it important or useful to point out that doing "something" unconditionally is a special case of doing "something" only for certain values of "a?" -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Tobias Schwinger <tschwinger@neoscientists.org> writes:
I don't believe it's metaprogramming specific -- let's clear up the logic, first:
it is unclear to me whether the common case is "ignoring an aspect" or if it is really "allowing a match for any variation of an aspect"
Given a variable 'a' which can be either '1', '2' or '3' it doesn't make a difference:
if ((a == 1) || (a == 2) || (a == 3)) // match any variation of a { // do something }
is logically equivalent to
// no if -- just ignore a { // do something }
which I can do by "ignoring an aspect."
Equivalence is commutative:
You can ignore 'a' by allowing any variation and you can allow any variation by ignoring 'a' -- no difference, again.
Making any difference would be talking about implementation details in a parapraph about plain logic.
Isn't this a complicated way of saying something simple? Is it
It undoubtfully is ;-). And awfully over-formalized. It's clear, though.
important or useful to point out that doing "something" unconditionally is a special case of doing "something" only for certain values of "a?"
It generally isn't. However, I believe it makes some sense to menion the case in the particular case of the paragraph we are discussing here. To try the section back-merged into the text see: http://lists.boost.org/boost/2005/06/29469.php Thanks, Tobias
When classifying types, it is often necessary to test for any one of several variations of an aspect. A common case is allowing a match for any variation of an aspect. This is done by ignoring that aspect and is implemented by using an "unspecified_*" tag. For example, to allow a match For any decoration would require using the <tt>unspecified_decoration</tt> tag.
That's probably my favorite so far.
I just wanted to throw in my $.02. I'll go back into lurker mode now. :)
Or maybe you should lurk less, and post more :-) John.
"John Maddock" <john@johnmaddock.co.uk> writes:
When classifying types, it is often necessary to test for any one of several variations of an aspect. A common case is allowing a match for any variation of an aspect. This is done by ignoring that aspect and is implemented by using an "unspecified_*" tag. For example, to allow a match For any decoration would require using the <tt>unspecified_decoration</tt> tag.
That's probably my favorite so far.
Very nice, but "this" needs an antecedent. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Hi, Joe Greer, Joe wrote:
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> 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
Please excuse me for jumping into the middle of this discussion. I am only a budding metaprogrammer, so that influences how I read things like this, so bear with me. With this phrasing,
Being unfamiliar with a topic is a very valuable for a proof-reader (unfortunately also "fragile" because humans -- and especially those reading this list -- tend to learn quickly ;-) ). However, I don't believe this particular case is metaprogramming-specific -- let's clear up the logic, first:
it is unclear to me whether the common case is "ignoring an aspect" or if it is really "allowing a match for any variation of an aspect"
Given a variable 'a' which can be either '1', '2' or '3' it doesn't make a difference: if ((a == 1) || (a == 2) || (a == 3)) // match any variation of a { // do something } is logically equivalent to // no if -- just ignore a { // do something }
which I can do by "ignoring an aspect."
Equivalence is commutative: You can ignore 'a' by allowing any variation and you can allow any variation by ignoring 'a' -- no difference, again. Making any difference would be talking about implementation details in a parapraph about plain logic.
Neither quoted sentence seems long or complex. Perhaps there was something you snipped to which 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.
I have the following problems with this: - it's too long for a single paragraph - 80% focusses on a special case - it's not enirely true that it is /only/ useful testing for other aspects
In this paragraph, you are telling me that "ignoring an aspect" is "allow a match for any variation of that aspect" (sentence 2) and that "ignoring an aspect" is "using an "unspecified_*" tag" (sentence 3). The use of "means" in both sentences is awkward. It is also unclear that "allow a match for any variation of that aspect" is actually the same as "using an unspecified_* tag."
I tend to be more conversational in my writing, but I would be tempted to write something like:
When classifying types, it is often necessary to test for any one of several variations of an aspect. A common case is allowing a match for any variation of an aspect. This is done by ignoring that aspect and is implemented by using an "unspecified_*" tag. For example, to allow a match For any decoration would require using the <tt>unspecified_decoration</tt> tag.
This one suffers similar problems (error propagation).
I just wanted to throw in my $.02. I'll go back into lurker mode now. :)
Since my top-candidate is a different one (and the discussion on one paragraph splinters too much to be helpful), I just posted an updated version of the whole section on tag types. I'ld really like to know if it works for you! Thanks, Tobias
From: Tobias Schwinger <tschwinger@neoscientists.org>
Greer, Joe wrote:
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> 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 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.
I have the following problems with this: - it's too long for a single paragraph
Not at all. It has all of four sentences. Well formed paragraphs can have many more sentences.
- 80% focusses on a special case
That special case required the most explanation.
- it's not enirely true that it is /only/ useful testing for other aspects
I'm looking forward to your explanation of this (I asked about it in reply to your omnibus reply). -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart wrote:
From: Tobias Schwinger <tschwinger@neoscientists.org>
Greer, Joe wrote:
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> 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 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.
I have the following problems with this: - it's too long for a single paragraph
Not at all. It has all of four sentences. Well formed paragraphs can have many more sentences.
Oh, I didn't mean to say it's otherwise ill-formed. Just that it is too long for my highly subjective taste in this context!
participants (2)
-
David Abrahams -
Greer, Joe -
John Maddock -
Rob Stewart -
Tobias Schwinger