please don't use keyword "where" for the concept facility - C++ language, library and standards

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

please don't use keyword "where" for the concept facility

C++Talk.NET Forum Index -> C++ language, library and standards

View previous topic :: View next topic

Author

Message

Howard Gardner
Guest

Posted: Mon Jul 17, 2006 10:43 pm Post subject: please don't use keyword "where" for the concept facility

"where" already has a deeply ingrained meaning (from SQL). I think that you will generate a lot of confusion if you use it. "requires" seems to express the relationship more clearly anyway. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Guest

Posted: Mon Jul 17, 2006 10:43 pm Post subject: Re: please don't use keyword "where" for the concept facilit

Howard Gardner wrote:

Quote:

"where" already has a deeply ingrained meaning (from SQL). I think that
you will generate a lot of confusion if you use it.

Also, it seems that "where" is already a popular variable name in C++:

<http://koders.com/?s=where&_%3Abtn=Search&_%3Ala=Cpp&_%3Ali=*>

<http://www.codase.com/search/text?join=where+&scope=variable%2Fname&lang=c%2B%2B&project=&search=Search>

And is used at least once in the linux kernel (C code):

<http://lxr.linux.no/ident?i=where>

Derek.

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Douglas Gregor
Guest

Posted: Mon Jul 17, 2006 10:43 pm Post subject: Re: please don't use keyword "where" for the concept facilit

derek (AT) antiquark (DOT) com wrote:

Quote:

Howard Gardner wrote:
"where" already has a deeply ingrained meaning (from SQL). I think that
you will generate a lot of confusion if you use it.

Perhaps. It depends on whether the two "where"s could ever be used in
the same context (causing an ambiguity) and how divergent the meanings
actually are. In some cases, reuse of a name can help make new concept
[*] more accessible, by relating it to what the reader already
understands. Is this such a case? Perhaps it is:

The "where" in SQL is used to limit the applicability of a query to
results that meet the requirements stated in the where clause, e.g.,

SELECT * FROM Persons
WHERE City='Sandnes'

This only accepts records that meet the requirement City='Sandnes'.

The "where" in Concepts is used to limit the applicability of a
template to parameters that meet the requirements stated in the where
clause, e.g.,

template<typename T>
where LessThanComparable<T>
const T& min(const T& x, const T& y);

This only accepts types T that meet the requirement
'LessThanComparable<T>' (or, "T is LessThanComparable").

Note that C# 2.0's generics use "where" for same same purpose (to
constrain a generic class/function). I wonder if they've run into
problems with SQL's "where"? I imagine it hasn't been a big problem,
since C# 3.0 looks like it will overload the "where" keyword
(introduced for generics) for its in-language SQL support. That would
surely complicate the problem.

Quote:

Also, it seems that "where" is already a popular variable name in C++:

http://koders.com/?s=where&_%3Abtn=Search&_%3Ala=Cpp&_%3Ali=*

http://www.codase.com/search/text?join=where+&scope=variable%2Fname&lang=c%2B%2B&project=&search=Search

This could be an issue. Every new keyword in C++0x is going to break
existing code. We have to weigh the cost of breaking code against the
cost of having keywords that are ugly or don't say what we want them
to.

Quote:

And is used at least once in the linux kernel (C code):

http://lxr.linux.no/ident?i=where

Is the Linux kernel typically compiled with a C++ compiler? If not, we
don't need to worry about it.

Cheers,
Doug

[*] Pun intended.

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Edward Diener No Spam
Guest

Posted: Tue Jul 18, 2006 5:39 am Post subject: Re: please don't use keyword "where" for the concept facilit

Douglas Gregor wrote:

Quote:

derek (AT) antiquark (DOT) com wrote:
Howard Gardner wrote:
"where" already has a deeply ingrained meaning (from SQL). I think that
you will generate a lot of confusion if you use it.

Perhaps. It depends on whether the two "where"s could ever be used in
the same context (causing an ambiguity) and how divergent the meanings
actually are. In some cases, reuse of a name can help make new concept
[*] more accessible, by relating it to what the reader already
understands. Is this such a case? Perhaps it is:

The "where" in SQL is used to limit the applicability of a query to
results that meet the requirements stated in the where clause, e.g.,

SELECT * FROM Persons
WHERE City='Sandnes'

This only accepts records that meet the requirement City='Sandnes'.

The "where" in Concepts is used to limit the applicability of a
template to parameters that meet the requirements stated in the where
clause, e.g.,

template<typename T
where LessThanComparable<T
const T& min(const T& x, const T& y);

This only accepts types T that meet the requirement
'LessThanComparable<T>' (or, "T is LessThanComparable").

Note that C# 2.0's generics use "where" for same same purpose (to
constrain a generic class/function). I wonder if they've run into
problems with SQL's "where"? I imagine it hasn't been a big problem,
since C# 3.0 looks like it will overload the "where" keyword
(introduced for generics) for its in-language SQL support. That would
surely complicate the problem.

Also, it seems that "where" is already a popular variable name in C++:

http://koders.com/?s=where&_%3Abtn=Search&_%3Ala=Cpp&_%3Ali=*

http://www.codase.com/search/text?join=where+&scope=variable%2Fname&lang=c%2B%2B&project=&search=Search

This could be an issue. Every new keyword in C++0x is going to break
existing code. We have to weigh the cost of breaking code against the
cost of having keywords that are ugly or don't say what we want them
to.
Perhaps C++ should begin to accept the idea, at least for any added

keywords at this juncture of the language, that the keyword when out of
context from its intended use can be a valid name. In the case of
'where', in which the proposal limits the type of a template in defined
ways, the use of 'where' in innumerable other contexts would suggest a
user-defined name and therefore not break other code.

In C++/CLI almost all of the new keywords are context sensitive and have
little chance of impacting the use of those words by C++ programmers in
their code. I do not see why C++ can not consider going in that
direction also.

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Douglas Gregor
Guest

Posted: Tue Jul 18, 2006 6:51 pm Post subject: Re: please don't use keyword "where" for the concept facilit

Howard Gardner wrote:

Quote:

I get the analogy: where is to template as where is to select.

It will lead a lot of people to: template is to where as select is to
where. If you work real hard, you can probably make that analogy fit in
some fuzzy way, and end up with false notions as a result.

It's not fair that people perform illegitimate operations on analogies,
but they do.

Push any analogy too far and it breaks down.

I don't mean to imply that we should use the SQL analogy when teaching
concepts/models, because I wouldn't do so. The analogy was meant only
to illustrate that SQL "where" and concepts "where" serve essentially
the same purpose: restricting the applicability of a select (SQL) or
template (C++).

Quote:

Everyone associates certain meanings with certain keywords... I see
"requires" and I immediately think of preconditions, which document
requirements that are checked at run-time or used for optimization, but
are otherwise irrelevant to the declaration. That's certainly not the
meaning we want for this clause, because (as Dave Abrahams points out)
it doesn't capture how where-clauses interact with overloading and the
type system.

For some part of the C++ community, "where" has deeply-ingrained
meanings from SQL. For others, it has deeply-ingrained meanings from
C#. The C# analogy is strong ("where" means the same thing), whereas
the SQL analogy is weak (even misleading, if pushed too far). By
changing "where" to something else, we help the SQL group while hurting
the C# group. Which group do we favor? I think that the damage caused
to the SQL group caused by the weak "where" analogy is far less than
the damage caused to the C# group by using a completely different
keyword for precisely the same facility in C#.

Doug

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Edward Diener No Spam
Guest

Posted: Wed Jul 19, 2006 5:01 am Post subject: Re: please don't use keyword "where" for the concept facilit

kanze wrote:

Quote:

ThosRTanner wrote:
Douglas Gregor wrote:

This could be an issue. Every new keyword in C++0x is going
to break existing code. We have to weigh the cost of
breaking code against the cost of having keywords that are
ugly or don't say what we want them to.

Isn't it possible to (re)design the compilers so that certain
keywords are only recognised as a keyword when it in the
context a keyword is appropriate, and other uses of it are
presumably expected to mean something else.

It's certainly possible. I once published a paper on how to
modify yacc to support this. I had to compile a language where
something like "if if = then then then = else else else = if"
was a perfectly legal statement.

Whether it is a good idea or not is another question. Examples
like the above certainly don't argue in its favor.

I find the above example, of the use of 'where' in a particular context,
as precisely arguing in the suggestion's favor, which is an argument I
also made in this thread in answer to Doug Gregor's message at almost
exactly the same time.

Why do you then aver that this example does not argue in favor of
context sensitive keywords ?

Quote:

And it
doesn't really solve the problem of use in existing code---only
banning the preprocessor would do that.

Context sensitive keywords perecisely solve the problem of use in
existing code for the vast majority of conflicts which could occur. Just
because someone could define a macro named 'where' is no reason to throw
out the whole concept of context sensitive keywords. Furthermore it is
common practice to use all uppercase alphabetics for macro names, which
would make a clash between a context sensitive keyword and a macro name
even rarer.

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Joe Gottman
Guest

Posted: Wed Jul 19, 2006 5:30 am Post subject: Re: please don't use keyword "where" for the concept facilit

"Edward Diener No Spam" <eldiener_no_spam_here (AT) earthlink (DOT) net> wrote in
message news:JXWug.9574$PE1.7305 (AT) newsread2 (DOT) news.pas.earthlink.net...

Quote:

In C++/CLI almost all of the new keywords are context sensitive and have
little chance of impacting the use of those words by C++ programmers in
their code. I do not see why C++ can not consider going in that direction
also.

Aren't some keywords already somewhat context sensitive? I know that the
meaning of const and static varies depending on where in the program they
are used. If the new semantics of "auto" are approved then it will also be
context sensitive.

Joe Gottman

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Frederick Gotham
Guest

Posted: Wed Jul 19, 2006 7:20 am Post subject: Re: please don't use keyword "where" for the concept facilit

Edward Diener No Spam posted:

Quote:

Furthermore it is common practice to use all uppercase alphabetics for
macro names, which would make a clash between a context sensitive
keyword and a macro name even rarer.

I would go further to condemn the use of lowercase letters for macro names
altogether, and not give them any consideration with regard to introducing
keywords.

Programmers certainly do have different styles; for example, some start the
name of a class or function with a capital letter, e.g.:

class Catalogue {

void Func()

while others don't.

However, has there ever been a substantial number of people who have used
lowercase names for macros?

--

Frederick Gotham

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

James Dennett
Guest

Posted: Wed Jul 19, 2006 9:11 am Post subject: Re: please don't use keyword "where" for the concept facilit

Joe Gottman wrote:

Quote:

"Edward Diener No Spam" <eldiener_no_spam_here (AT) earthlink (DOT) net> wrote in
message news:JXWug.9574$PE1.7305 (AT) newsread2 (DOT) news.pas.earthlink.net...

In C++/CLI almost all of the new keywords are context sensitive and have
little chance of impacting the use of those words by C++ programmers in
their code. I do not see why C++ can not consider going in that direction
also.

Aren't some keywords already somewhat context sensitive?

Not in this sense.

Quote:

I know that the
meaning of const and static varies depending on where in the program they
are used. If the new semantics of "auto" are approved then it will also be
context sensitive.

But it is always a keyword, as are const and static. By
"context-sensitive keywords" we generally mean identifiers
which are keywords only in certain contexts.

My personal feeling is that clarity is impaired by such
identifiers. C++ has few enough keywords that it is
reasonable to expect competent programmers to be familiar
with them all (which contrasts with the fact that it is
not reasonable to expect all competent C++ developers to
be familiar with every name in the standard library).

The only arguments for context-sensitive keywords appear
to be avoiding breakage of existing code, but I hold that
the cost in terms of lost clarity is not a good trade-off.

Using _Keywords with macros for more readable names is
also a losing proposition, as header files would have
to use the _Uglified versions in many cases, so readers
would need to be familiar with both forms.

I lean towards allowing economical use of new keywords
in C++0x, even at the cost of breaking some existing
code. I'm not sure how much support that has within
the Committee; certainly many members are strongly
committed to minimizing such breakage, while others
(such as myself) feel that the cost of avoiding all
new keywords is too high.

static_assert appears to have already made it into the
working paper as a new keyword, so there's cause for
hope.

-- James

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Edward Diener No Spam
Guest

Posted: Wed Jul 19, 2006 9:11 am Post subject: Re: please don't use keyword "where" for the concept facilit

Joe Gottman wrote:

Quote:

I agree that some keywords are context sensitive already, but what I am
arguing is that context sensitive keywords which could be added to the
language be also allowable as normal C++ names in all situations in
which they are not used in their context sensitive case(s). This would
mean that additions of certain context sensitive keywords to C++ would
not break user's code which now uses the keyword as a name, as long as
it can be guaranteed that the C++ name could not occur in exactly the
same position where the equivalent new context sensitive name would occur.

My suggestion is based on the fact that the standard C++ committee
appears to be highly concerned that any new additions to the C++
language not break any code which already exists. If the tack is always
taken is that new language additions, in the form of new keywords, could
always break current code based on the fact that a programmer could be
currently using the new keyword as a C++ name, my suggestion of new
keywords being possibly context sensitive could solve that problem
depending on the nature of the addition.

The proposed use of 'where' to restrict the types used as template
parameters is an excellent example of such a case. Another good current
example of this is the 'for' keyword, since 'for (..;..;..)' can never
mean anything else in C++, wvwn if 'for' were allowable as a C++ name. A
bad current example is the 'while' keyword, since 'while (..an
expression convertible to a boolean expression)' can mnemonically be
confused with the ever popular 'somename (..an expression convertible to
a boolean expression)' which could easily be a function call among many
other usages.

I just hate to think that the C++ language must forever be in stasis
because of the fear of breaking existing code in some way. Context
sensitive keywords offer a possible way out of that impasse.

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Howard Gardner
Guest

Posted: Wed Jul 19, 2006 8:10 pm Post subject: Re: please don't use keyword "where" for the concept facilit

David Abrahams wrote:

Quote:

hgardner (AT) rawbw (DOT) com (Howard Gardner) writes:

If this is the code:

template<typename T
requires LessThanComparable<T
const T &
min(const T & l, const T & r);

Then this explains it:

"The requires clause indicates that the template can only be
instantiated for a type T if the type T models the concept
LessThanComparable".

That explanation is shorter. Assuming that the reader understands
concept/models, it is clearer. It doesn't mention irrelevant things
like sql select. It doesn't rely on a weak analogy. It doesn't invite
false analogies.

It also fails to capture the fact that the function isn't even
considered for overload resolution if T isn't LessThanComparable, and

"The requires clause indicates that the template will be considered
during overload resolution if and only if the type T models the concept
LessThanComparable."

Quote:

doesn't leave much room in the imagination for refinement-based
overload resolution.

The code does not illustrate this, so the explanation does not address it.

Quote:

"where" conjures a c# analogy for you rather than a sql analogy, right?

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Howard Gardner
Guest

Posted: Wed Jul 19, 2006 11:50 pm Post subject: Re: please don't use keyword "where" for the concept facilit

Douglas Gregor wrote:

Quote:

Howard Gardner wrote:
I get the analogy: where is to template as where is to select.

It will lead a lot of people to: template is to where as select is to
where. If you work real hard, you can probably make that analogy fit in
some fuzzy way, and end up with false notions as a result.

It's not fair that people perform illegitimate operations on analogies,
but they do.

Push any analogy too far and it breaks down.

I don't mean to imply that we should use the SQL analogy when teaching
concepts/models, because I wouldn't do so. The analogy was meant only
to illustrate that SQL "where" and concepts "where" serve essentially
the same purpose: restricting the applicability of a select (SQL) or
template (C++).

Explaining things by analogy can be good, or it can be bad.

If the analogy is strong then it conveys a lot of true things, there is
little risk of conveying false things, and it is succinct. It's good to
use strong analogies.

If the analogy is weak then it doesn't convey many true things, there is
great risk of conveying false things, or it is verbose. It's bad to use
weak analogies.

The analogy to sql is weak. If you don't carefully qualify it, then it
runs a large risk of conveying false things. If you do carefully qualify
it, then it is verbose. In either event, it's just as easy to explain
the behavior of where without the analogy at all.

Quote:

If you write the same explanation using the keyword "where", you invite
the reader to manufacture his own analogy. Using "where" brings the
analogy into play because "where" already has a deeply ingrained
meaning. You can either address it directly or not, but either way
you'll make things worse.

Everyone associates certain meanings with certain keywords... I see
"requires" and I immediately think of preconditions, which document
requirements that are checked at run-time or used for optimization, but
are otherwise irrelevant to the declaration. That's certainly not the
meaning we want for this clause, because (as Dave Abrahams points out)
it doesn't capture how where-clauses interact with overloading and the
type system.

I don't think that "requires" is ingrained in people's heads the way
that "where" is. It might, however, be pretty deeply ingrained in the
heads of people who are likely to be interested in the where clause.

Quote:

For some part of the C++ community, "where" has deeply-ingrained
meanings from SQL. For others, it has deeply-ingrained meanings from
C#. The C# analogy is strong ("where" means the same thing), whereas
the SQL analogy is weak (even misleading, if pushed too far). By
changing "where" to something else, we help the SQL group while hurting
the C# group. Which group do we favor?

Members of group A want to understand "where" in c++ and reflexively
conjures c# or other strong analogies. They want to do GP in c++ and
have already learned to do it using c# or some other tool that uses
"where" in the same way. Choosing "where" helps them.

Members of group B want to understand "where" in c++ and reflexively
conjures sql or other weak analogies. They want to do GP in c++, have
not learned to do it in c# or any other tool that uses the keyword
"where" in the same way, but have used some tool that uses the keyword
"where" in a different way. Choosing "where" hurts them.

Members of group C want to understand "where" in c++ but don't
reflexively conjure any analogies at all. They want to do GP in c++ but
don't have any ingrained associations with the keyword "where". Choosing
"where" is neutral for them.

I think that group B is much larger than group A, and that group C is
much larger than both of them together. I can't prove it.

Quote:

I think that the damage caused
to the SQL group caused by the weak "where" analogy is far less than
the damage caused to the C# group by using a completely different
keyword for precisely the same facility in C#.

I'm in group B. When I read "where"

http://www.artima.com/cppsource/cpp0x.html

I conjured bad analogies which created confusion, and ended up thinking
that "where" invokes "requires". This confusion persisted until I saw
your objection to "requires", which prompted me to find

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1886.pdf

from which I gleaned that "where" actually invokes "enable_if", and it's
"assert" that invokes "requires".

That paper is pretty heavy going for me--because it relies on the
formalism in

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1885.pdf

so I *still* may have it wrong.

I think that this example illustrates the relationship between "where"
and "assert".

template< typename T >
where Assignable< T > // because of this
void example()
{
assert Assignable< T >; // this will never cause an error
}

This is the same example, except that both "where" and "assert" are
replaced by "models".

template< typename T >
models Assignable< T > // because of this
void example()
{
models Assignable< T >; // this will never cause an error
}

I think that this is clearer because the two uses of "models" are the
same idea--that T models Assignable--occurring in two slightly different
contexts, and it's the difference between the contexts that is important.

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Steve Hicks
Guest

Posted: Fri Jul 21, 2006 4:14 pm Post subject: Re: please don't use keyword "where" for the concept facilit

Howard Gardner wrote:

Quote:

Howard Gardner wrote:
I get the analogy: where is to template as where is to select.

It will lead a lot of people to: template is to where as select is to
where. If you work real hard, you can probably make that analogy fit in
some fuzzy way, and end up with false notions as a result.

The analogy to sql is weak. If you don't carefully qualify it, then it
runs a large risk of conveying false things. If you do carefully qualify
it, then it is verbose. In either event, it's just as easy to explain
the behavior of where without the analogy at all.

Please excuse my ignorance here, but I have never used C#, while I am
familiar with SQL. However, I don't understand what the problem is.
Maybe I've fallen victim to this exact pitfall and am just too stubborn
to even see it, but it seems to me that the insight I gain from SQL is
plenty. Notwithstanding the fact that SQL is about selecting from
*existing* records, while C++ is about limiting which of the multitude
of possible templates are allowed to be instantiated, it seems to hold
up pretty well.

Quote:

Members of group B want to understand "where" in c++ and reflexively
conjures sql or other weak analogies. They want to do GP in c++, have
not learned to do it in c# or any other tool that uses the keyword
"where" in the same way, but have used some tool that uses the keyword
"where" in a different way. Choosing "where" hurts them.

I just don't get what you're saying here. I'm not sure we can assume
that most SQL folks will take this analogy "too far" (which I'm not
sure I understand even), rather than just far enough to get helpful
insight from it.

Quote:

I think that group B is much larger than group A, and that group C is
much larger than both of them together. I can't prove it.

I'm in group B. When I read "where"

http://www.artima.com/cppsource/cpp0x.html

I conjured bad analogies which created confusion, and ended up thinking
that "where" invokes "requires". This confusion persisted until I saw
your objection to "requires", which prompted me to find

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1886.pdf

from which I gleaned that "where" actually invokes "enable_if", and it's
"assert" that invokes "requires".

And this is where my own understanding comes to the test -- First, I
didn't think "requires" was even a keyword anyone was considering.
This is my understanding of "where". Please correct me if I'm wrong.
Adding a "where" clause to a template prevents it from being
instantiated in the first place. So if I define

template <typename T> where Is_Numeric<T>
T sum_of_squares(T a, T b);

and then try to call sum_of_squares() on a pair of strings, I will get
an error that there is no function found with the correct signature.
This seems to be about the same as if I do a SELECT * FROM mytable
WHERE (index>10) but there are no records which match, despite the fact
that there *are* records in mytable. In this case, the "FROM" or maybe
even the "SELECT *" is (weakly) analgous to the function signature,
which *does* match, and the WHERE is then rejecting whatever matches
where found.

Here is where I get even more confused by other people's confusion. If
I were to write my above example as

template <typename T> T sum_of_squares(T a,T b) {
static_assert<Is_Numeric<T> >; // not sure about syntax, but you get
the idea
return a*a+b*b;
}

then I would get possibly a more descriptive error message (string is
not numeric) than if I just defined it without the assert (string can't
be multiplied), but it seems that this solution is inherently flawed,
because it is already *instantiating* the template which we didn't want
to even instantiate in the first place. This doesn't seem at all
analagous to WHERE from SQL.

Quote:

I agree -- but as explained above, I don't see the sense in this
statement. "Where" and "assert" do very different things. "Assert"
seems to me to be a safeguard applied after we already screwed up and
instantiated the wrong template, while "where" is a preventative
measure which makes sure we only instantiate the templates we really
mean to.

Quote:

This is the same example, except that both "where" and "assert" are
replaced by "models".

template< typename T
models Assignable< T > // because of this
void example()
{
models Assignable< T >; // this will never cause an error
}

I think that this is clearer because the two uses of "models" are the
same idea--that T models Assignable--occurring in two slightly different
contexts, and it's the difference between the contexts that is important.

Here, I vehemently disagree, for reasons noted above. It seems to me
that these two "model"s do very different things, since "where" and
"assert" really are different beasts.

Overall, I don't see a problem with "where" coming from a SQL point of
view. Nor do I get the difference between "where" and "requires". But
I hardly reckon my own experience much compared to the rest of the
folks posting here (and I certainly couldn't make it through either of
those technical articles), so if someone could enlighten me as to where
my misunderstanding is, or as to the specific problem they foresee, I
would really appreciate the insight.

Steve Hicks

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Howard Gardner
Guest

Posted: Fri Jul 21, 2006 10:05 pm Post subject: Re: please don't use keyword "where" for the concept facilit

Steve Hicks wrote:

Quote:

Howard Gardner wrote:
Howard Gardner wrote:
I get the analogy: where is to template as where is to select.

It will lead a lot of people to: template is to where as select is to
where. If you work real hard, you can probably make that analogy
fit in
some fuzzy way, and end up with false notions as a result.

The analogy to sql is weak. If you don't carefully qualify it, then it
runs a large risk of conveying false things. If you do carefully qualify
it, then it is verbose. In either event, it's just as easy to explain
the behavior of where without the analogy at all.

Please excuse my ignorance here, but I have never used C#, while I am
familiar with SQL. However, I don't understand what the problem is.
Maybe I've fallen victim to this exact pitfall and am just too stubborn
to even see it, but it seems to me that the insight I gain from SQL is
plenty. Notwithstanding the fact that SQL is about selecting from
*existing* records, while C++ is about limiting which of the multitude
of possible templates are allowed to be instantiated, it seems to hold
up pretty well.

You've conjured a better analogy than I did. Yours is better because it
didn't lead you to error. It's still not a good analogy, and you can tell.

Here's some code:

template<typename T>
where LessThanComparable<T>
const T & min(const T & l, const T & r);

Here's a straight explanation of it:

"The where clause indicates that the template will be considered during
overload resolution if and only if the type T models the concept
LessThanComparable."

The c# analogy is a good one, because apparently this is a good
alternative explanation:

"The where clause works like it does in c#."

The sql analogy is bad, because this alternative explanation is clearly
awful:

"The where clause works like it does in sql."

By the time you fix the explanation based on the sql analogy it s longer
than the straight explanation. That's the hallmark of a bad analogy: it
makes the explanation worse.

Quote:

And this is where my own understanding comes to the test -- First, I
didn't think "requires" was even a keyword anyone was considering.

Just me, and only while I was suffering from the confusion that my badly
conjured analogy caused me.

Quote:

This is my understanding of "where". Please correct me if I'm wrong.
Adding a "where" clause to a template prevents it from being
instantiated in the first place. So if I define

template <typename T> where Is_Numeric<T
T sum_of_squares(T a, T b);

and then try to call sum_of_squares() on a pair of strings, I will get
an error that there is no function found with the correct signature.

It does prevent it from being instantiated, but it specifically does
that by preventing it from even being considered for instantiation. The
compiler throws up an error referring to the call point in the user's
code, just as if the template wasn't there.

Contrast that with preventing it from being instantiated by discovering
an error during an attempt to instantiate it. That would cause the
compiler to throw up an error deep in the template.

The distinction is one of the feature's prime motivations.

Quote:

This seems to be about the same as if I do a SELECT * FROM mytable
WHERE (index>10) but there are no records which match, despite the fact
that there *are* records in mytable. In this case, the "FROM" or maybe
even the "SELECT *" is (weakly) analgous to the function signature,
which *does* match, and the WHERE is then rejecting whatever matches
where found.

Why on earth are we discussing SQL stuff in c.s.c++?

(Rhetorical. I'm making a point about another flaw with weak analogies:
they require a lot of discussion, which is only tangentially related to
the topic at hand. They are distracting.)

Quote:

Here is where I get even more confused by other people's confusion. If
I were to write my above example as

template <typename T> T sum_of_squares(T a,T b) {
static_assert<Is_Numeric<T> >; // not sure about syntax, but you get
the idea
return a*a+b*b;
}

then I would get possibly a more descriptive error message (string is
not numeric) than if I just defined it without the assert (string can't
be multiplied), but it seems that this solution is inherently flawed,
because it is already *instantiating* the template which we didn't want
to even instantiate in the first place. This doesn't seem at all
analagous to WHERE from SQL.

The syntax from the paper is:

assert Is_Numeric<T>;

assert is another new keyword. If the assert fails, it causes an
immediate error. Hopefully, the diagnostic will indicate which part of
the concept T fails to model.

That will help people using templates. If the compiler tells you that
there is no match for T, then you can steal the where clause from the
template you think should match and turn it into an assert. The compiler
might then tell you what's wrong with T.

{
string a, b;
// sum_of_squares( a, b ); no match - why?!?!
assert Is_Numeric< string >; // oh, I see
}

It will also help when writing templates, because it will help develop
with developing archetypes.

Quote:

I think that this example illustrates the relationship between "where"
and "assert".

template< typename T
where Assignable< T > // because of this
void example()
{
assert Assignable< T >; // this will never cause an error
}

I agree -- but as explained above, I don't see the sense in this
statement. "Where" and "assert" do very different things. "Assert"
seems to me to be a safeguard applied after we already screwed up and
instantiated the wrong template, while "where" is a preventative
measure which makes sure we only instantiate the templates we really
mean to.

The only point in that code is to illustrate that Assignable is doing
the same thing in both places: checking T for syntax.

Quote:

I counter-vehemently-disagree :)

Both uses of models are doing precisely the same thing. They are
checking type T for the syntax that it is required to have in order to
model the concept Assignable.

The difference lies entirely in the implication of failure. In the first
use, failure implies "ignore this template." In the second use, failure
implies "spew forth an diagnostic."

If this is the truth:

template< typename T >
"consider instantiating this if T models Assignable"
void example()
{
"spew a diagnostic if T does not model Assignable"
}

then transforming it to this:

template< typename T >
where Assignable< T >
void example()
{
assert Assignable< T >;
}

emphasizes the difference in the way that failure is treated.

Transforming it to this:

template< typename T >
models Assignable< T >
void example()
{
models Assignable< T >;
}

emphasizes the similarity in the test that is made.

I mildly prefer emphasizing the similar tests, strictly because doing so
would let us use one of GP's core vocabulary words (concept, model,
refinement, archetype) for the keyword. I think its a probably a little
easier to explain (and therefore to understand) everything that way. I'm
not sure though, and I wouldn't have bothered with arguing over that.

If it's better for some reason to emphasize the difference, though, then
this transform is easier to explain (and therefore to understand) than
the one using "where":

template< typename T >
mcfrontalot Assignable< T >
void example()
{
assert Assignable< T >;
}

It is easier to explain because the keyword "mcfrontalot" will not
conjure weak analogies that must be addressed.

It's like building a house, which is much easier to do on a vacant lot
than it is on the spot where another house stands.

Quote:

Overall, I don't see a problem with "where" coming from a SQL point of
view.

It led me to an actively harmful analogy. You did better work, and so
arrived at an analogy that is merely useless.

Quote:

Nor do I get the difference between "where" and "requires".

requires is a core vocabulary word from design by contract. I think that
Doug is right about using it for a keyword: it would probably conjure
bad analogies for people who do design by contract.

http://www.ddj.com/184405997
http://www.eventhelix.com/RealtimeMantra/Object_Oriented/design_by_contract.htm

Quote:

But I hardly reckon my own experience much compared to the rest of the
folks posting here (and I certainly couldn't make it through either of
those technical articles),

Meh, we're just programmers. Well, I am anyway.

Quote:

so if someone could enlighten me as to where
my misunderstanding is, or as to the specific problem they foresee, I
would really appreciate the insight.

I don't think you have a misunderstanding. Of course that might just
mean we both have the same misunderstanding. That's a real danger,
because we both founded our understanding on weak analogies. (Rhetorical
again. I'm pretty sure we've got it right now.)

I think that the best argument in favor of using "where" is that it
conjures strong analogies from some other languages. I think that the
best argument against using it is that it will conjure weak sql
analogies far more often.

I get the sense that this isn't really open to discussion, so I'll stop.
I've got some code to write anyway.

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Douglas Gregor
Guest

Posted: Tue Jul 25, 2006 9:51 pm Post subject: Re: please don't use keyword "where" for the concept facilit

Howard Gardner wrote:

Quote:

Here's some code:

template<typename T
where LessThanComparable<T
const T & min(const T & l, const T & r);

The sql analogy is bad, because this alternative explanation is clearly
awful:

"The where clause works like it does in sql."

I guess I don't understand exactly where the SQL analogy breaks down.
Back in the beginning of this thread, you mentioned that it might be
turned around like this:

Quote:

It will lead a lot of people to: template is to where as select is to
where. If you work real hard, you can probably make that analogy fit in
some fuzzy way, and end up with false notions as a result.

I can't imagine that anyone would try to take the analogy that far. A
C++ programmer knows what a template is, even if s/he doesn't
understand all of the details (who does?), and is unlikely to confuse a
template with a SQL select statement. The power of analogies is that
they adapt to their context: if we then say "with concepts, the where
clause on a template is like the where clause on a select statement" to
a SQL-savvy C++ programmer, I'd expect her to imagine how WHERE
modifies a SELECT (it restricts the result set) and apply that notion
to templates (it restricts the allowed type parameters). On reading
Steve Hicks reply, I feel even better about the SQL analogy.

Could you perhaps enumerate the problems you see with the analogy?
Where does it actually break down, and would a SQL-savvy C++ programmer
(who knows what templates and select statements are, already) consider
taking the analogy that far?

Quote:

The "assert" keyword is not used in the latest concepts proposal,
N2042. N2042 is the proposal that we're bringing to the C++ committee.
It is a bit different from earlier proposals, and probably worth a
re-read for those interested:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2042.pdf

Quote:

It will also help when writing templates, because it will help develop
with developing archetypes.

Archetypes aren't necessary any more. Complete type-checking for
constrained templates catches all of the errors that archetypes could
catch (and more that archetypes would miss), with much-improved error
messages and less effort on the user's part.

Quote:

It led me to an actively harmful analogy.

I'm still grasping to understand how it can be harmful.

Quote:

You did better work, and so
arrived at an analogy that is merely useless.

Quote:

But I hardly reckon my own experience much compared to the rest of the
folks posting here (and I certainly couldn't make it through either of
those technical articles),

Meh, we're just programmers. Well, I am anyway.

It's extremely important for us to hear reactions to concepts from
*everyone*. I've been working on concepts in C++ for several years,
have written a significant fraction of the concepts proposals and led
the implementation of the only concept-enabled C++ compiler and its
Standard Library. Concepts, "where", and everything in those proposals
is second nature to me, which makes it very hard for me to step back
and evaluate the terminology objectively. If the SQL analogy is bad or
harmful, I need to know why (because someone *will* ask).

As for N1885-6, they were originally meant for a different audience
(academic researchers in programming languages). I expect N2042 will be
much easier reading. As the October C++ committee meeting in Portland
draws closer, we'll provide much more introductory material (tutorials,
presentations, etc.). We would *really* appreciate feedback from
everyone.

Doug

---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

Display posts from previous:

	C++Talk.NET Forum Index -> C++ language, library and standards	All times are GMT
Page 1 of 1

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum