Re: [boost] [Review] Type Traits Extension by Frederic Bron - Review summary and decision

Subject: Re: [boost] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2011-05-08 01:42:54

On Wed, May 4, 2011 at 10:27 AM, Joachim Faulhaber
<afojgo_at_[hidden]> wrote:
>>
>
> Your main point is the spontaneous and commonly observed "spoken"
> version of those operator signs. And it took me a little by surprise
> that this aspect has not been risen before (or has it? I'm loosing
> overview).
>

"Spoken-ness" is one point.
Common usage is the other.
Related points, but there are differences...

>
>> I think about the general problem of naming (of variables in code,
>> etc) a lot (including Bertrand Russell's essays on "the King of
>> Spain", etc),
>
> sounds interesting, is the essay accessible via the web?
>

I had to do some googling: I'm pretty sure it was an essay called "On
Denoting" (http://en.wikipedia.org/wiki/On_Denoting).  Although I
think when I read it, it was in a book, one chapter called "the
definite article" and another called "the indefinite article", and I
recall thinking it was pretty funny that someone could write so much
about the word 'a' and so much about the word 'the' (and that I could
find it so interesting).
See also http://en.wikipedia.org/wiki/Theory_of_descriptions,
http://evans-experientialism.freewebspace.com/frege_russel_is.htm,
etc.

>
> So, a lot of your very interesting point of view relates to "spoken"
> language and "spoken" c++ in particular (also inner speaking while
> typing).
>
> ... I can not compare my auditive experience to yours because my
> "spoken operatorish" is in German ;-) which is also pretty bizarre,
> because c++ spoken by Germans it is a wild mixture of German and
> English words and typically operators are spoken in German by German
> c++ narrators. This happens in a way as if, in the face of reading c++
> operators the human brain degenerated to a lexical scanner that scans
> the tokens and translates them (using mother tongue) in those words
> sequentially that it has most frequently been drilled to use for the
> respective digits.
>
> As stated on the outset, this operatorish narrator produces seemingly
> natural results e.g.
> UK plus-equals
> DE plus-gleich
> for += that seems to be "paralell natural" for the two languages,
>
> but I have heard it producing cumbersome names like
> DE Prozent-gleich for %=  or
> DE Doppelpunkt-gleich for :=  (not c of course)
>
> because it seems not to "think" very much ;)
> Since no one ever says "modulus" for % in Germany, but everyone says
> "Prozent". Everyone would say
> DE Prozent-gleich for %=
> which would be 'percent-equals' in English.
>

I tend to call it - or at least speak it - percent-equals as well,
although I might not want to use that as the name in this library - it
could be confused with an operation that actually calculated
percentages.  Although, I guess since operators can be overloaded, in
some sense the symbolic name "percent" is more accurate than how it
operates on integers.  x % y doesn't mean modulus for arbitrary
classes.  Maybe it does calculate percentages.

> I see three Problems with your Spokenness Paradigm
>
> (1) Spokenness of operators leads to non systematic sometimes awkward
> conglomeration of parts.
> (2) There are loads of differences of spoken operators in different languages.
> (3) Spokenness as a guideline is again not consistently used.
> Specifically not used consistently within column A
>    We would, for example, need to name pre_increment as pre_plus_plus
>

Ah, but no one calls it pre-plus-plus.  This is where spokenness and
common usage diverge.  We call it pre and post increment when we need
to differentiate.  If it was understood in context, I would explain to
someone that "a list iterator overrides operator plus-plus to move to
the next node in the list".  But if I needed to give someone a task, I
would probably be more precise - "you need to use pre-increment here,
as it tends to be more efficient...".  Etc.

This, I think, is an important point.  Possibly more important than
"spokenness".  I think we, for the most part, have already decided the
names of these operators.  By "we" I mean programmers at large.  I
mean common usage.  Now maybe it is hard to measure common usage
(maybe tallying google search results would help), but I think common
usage has already decided it.  (And yes, google says "plus equals" is
10x more common than alternatives)  So it has already been determined
via the genetic algorithms of programmers using terms and having some
catching on and others not.

>
> Moreover the rationals that govern the choice of names is very simple. See
> https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators
>

That is a useful page.  Obviously anything that aligns with the
standard (current or C++0x) is pretty compelling.
That leaves, I think:

+=, -=,...   plus_equal vs plus_assign
<<...   left_shift vs shift_left
++...   pre_increment vs ...
-         unary_minus vs negate  (std uses negate but std doesn't have
anything for unary_plus)

~ and * are not in the standard, but I see no conflicting proposals
there.  And I'm NOT going to argue that symbols have no meaning (since
the can be overloaded) such that ~ should be called 'tilde' and *
should be called 'asterisk'.  I'm not going to argue that. I'm fine
with compliment and dereference.

- is in the standard as 'negate', but I find the 'unary_plus' matches
'unary_minus' argument compelling.  Of course, what would be even
better would be to find a name for unary + that matches negate - ie
'posit' or 'positate' or something :-)  Probably not going to happen.
So I could live with either, or even both - ie include unary_minus and
negate.  But I personally prefer unary_minus.  Not sure if I have a
good argument for why.

++ pre_increment, prefix_increment, pre_inc,... is there any argument
here?  I suspect not.  pre_increment works, I think.

<< left_shift vs shift_left.  I find 'shift_left' to be the verb, and
'left_shift' to be the noun - ie the name of the operator.  So I agree
with left_shift.

+= I left this for last, hoping to have a good argument or good
solution...  I just don't like plus_assign.  I see the idea of
separating comparison from assignment.  And the standard already set
the standard for comparison, so I don't suggest changing it to
equality or equivalence (nor do I suggest getting into the discussions
about the possible different meanings of equality, equivalence,
indentity, etc).  The best I can do is suggest "equals" vs "equal" -
ie note that the comparison operators use "equal" but multiplies,
divides, etc, add an 's', and basically, I would say "plus-equals" not
"plus-equal".  Actually, I read "x += y" as "plus-equal" but I read
"operator+=" as "operator plus-equals".
I don't feel that is a great argument.
So let me go back to common usage.  Let's assume all the others (<<,
++, ~, *, etc) are decided, and only the += problem is left.  If you
gave the table to N programmers, with everything filled in except the
+= group, and asked them to fill in the blanks... no wait.  Better
yet, show them the rest of the table, then let them go write some code
that requires type_traits::supports_+=, what will they automatically
to type?  I suspect plus_equals, or plus_equal or maybe even a
plus_assignment, but 0 will assume that is is called
supports_plus_assign or (has_plus_assign, etc).

In this case I think common usage is more important than a slight
ambiguity with equality.  (You could even argue that plus_equals is
*consistent* with equal_to, since they both use the same term for the
same(ish) symbol :-)
And/or feel free to argue that the standard should have used a term
like "equality" or "omparable" or something.  Basically the standard
used common usage, I think, and to be consistent with that, we should
too.  (You could also argue that the standard's usage of common usage
is an example of how it can later cause problems...)

Lastly, I find these type_traits useful, so I will use whatever is
decided, even if it is in German.  But I appreciate the effort of
finding good names.

Actually, the last thing I wanted to mention (again) is that I really
like "supports" over "has" or "can_call" or has_operator or etc.
Tony