syntax suggestion for concepts

[W Karas]

Would the fear factor for concepts be slightly reduced if,
instead of:

concept C<typename T>
{
typename T::S;
int T::mem();
int nonmem();
};

a new usage of :: was added to make concepts/
concept maps more consistent with class interfaces:

concept C<typename T>
{
typename S
int mem();
int ::nonmem();
};

A perhaps bad aspect of this is that multi-type
concepts could ONLY specify names prefixed with ::,
that is, this under the existing proposal:

concept D<typename U, typename V>
{
int U::umem();
int uandv(U u, V v);
};

would have to be changed to something like:

concept DD<typename U>
{
int umem();
};
concept D<typename U, typename V: DD<U>
{
int ::uandv();
};

(Or, the one reserve word "concept" could be
replaced with two: "algebra" for single-type
concepts, and "geometry" for multi-type
concepts. This would avoid the ubiquitous
:: in geometries.)

For orthogonality, this use of :: could be allowed in
class interfaces as well. Concepts and class interfaces
are both ways of describing type usage, so it seems
more intuitive to me that they be as similar as
possible.

[kwikius]

On 25 Feb, 14:57, "W Karas" <wka...@yahoo.c omwrote:

Would the fear factor for concepts be slightly reduced if,
instead of:

....

Your probably better off reposting the above to comp.std.c++.
That where they usually discuss this type of thing.

(Many of them don't like to associate with lowlife such as meself here
on comp.lang.c++ ;-) )

regards
Andy Little

[W Karas]

On Feb 25, 9:57 am, "W Karas" <wka...@yahoo.c omwrote:

Would the fear factor for concepts be slightly reduced if,
instead of:

concept C<typename T>
{
typename T::S;
int T::mem();
int nonmem();
};

a new usage of :: was added to make concepts/
concept maps more consistent with class interfaces:

concept C<typename T>
{
typename S
int mem();
int ::nonmem();
};

A perhaps bad aspect of this is that multi-type
concepts could ONLY specify names prefixed with ::,
that is, this under the existing proposal:

concept D<typename U, typename V>
{
int U::umem();
int uandv(U u, V v);
};

would have to be changed to something like:

concept DD<typename U>
{
int umem();
};
concept D<typename U, typename V: DD<U>
{
int ::uandv();
};

(Or, the one reserve word "concept" could be
replaced with two: "algebra" for single-type
concepts, and "geometry" for multi-type
concepts. This would avoid the ubiquitous
:: in geometries.)

For orthogonality, this use of :: could be allowed in
class interfaces as well. Concepts and class interfaces
are both ways of describing type usage, so it seems
more intuitive to me that they be as similar as
possible.

Another thought, not necessarily depedent on the
above, would be to allow class interfaces to
be defined using existing concepts. If C is
a concept, one possible sytax could be:

class X using C
{
// ... additional stuff not declared
// by C ...
};

But since this does indirectly introduce a
way of defining things in namespace-scope
as a part of a class interface declaration,
this seems another reason to allow the
:: prefix on defined names in a class
interface, for direct definition in
namespace scope within the class
interface.

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

[Douglas Gregor]

On Mar 5, 9:12 am, "W Karas" <wka...@yahoo.c omwrote:

Would the fear factor for concepts be slightly reduced if,
instead of:

[snip example of existing syntax]

a new usage of :: was added to make concepts/
concept maps more consistent with class interfaces:

concept C<typename T>
{
typename S
int mem();
int ::nonmem();
};

[snip]

I never saw the original message, so I'll reply to this part first.

Making concept syntax more consistent with class interfaces would not
help programmers understand concepts any better. It may reduce initial
anxiety, because concepts would look like object-oriented interfaces,
but the resemblance would only be skin-deep. Concepts support a
different programming paradigm---Generic Programming---and much of the
confusion I've seen about concepts comes from attempts to think of
them in object-oriented terms. New ideas and constructs should have
new syntax, to emphasize that they are different from existing ideas/
constructs. Sometimes syntactic similarity can be a good thing, but
not when it leads to many incorrect assumptions.

(Or, the one reserve word "concept" could be
replaced with two: "algebra" for single-type
concepts, and "geometry" for multi-type
concepts. This would avoid the ubiquitous
:: in geometries.)

My impression is that many programmers would react badly to "algebra"
and "geometry" as keywords for specific entities. Concepts are,
theoretically speaking, "multi-sorted algebras," but we've been banned
from saying that phrase in public :)

Another thought, not necessarily depedent on the
above, would be to allow class interfaces to
be defined using existing concepts. If C is
a concept, one possible sytax could be:

class X using C
{
// ... additional stuff not declared
// by C ...
};

We've thought about something like this, but there are two reasons we
did not include it:

- It again mixes object-oriented and generic programming ideas in a
way that will lead to confusion. I guarantee that, after showing an
example like the above to an audience, I will get two questions: (1)
why can't I just use ':' to inherit from C? and (2) can I declare a
variable of type C*? Neither question would arise without the
assumption that concepts are just another take on object-oriented
programming (they aren't), and we need to be very careful not to give
the impression that they are.

- If you want X to meet the requirements of C, write a concept_map
C<X>. Then, you cleanly separate what X "is" (i.e., it's data members,
member functions, superclasses, etc.) from how X maps onto a C.

Cheers,
Doug

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

[W Karas]

On Mar 5, 1:02 pm, "Douglas Gregor" <doug.gre...@gm ail.comwrote:

On Mar 5, 9:12 am, "W Karas" <wka...@yahoo.c omwrote:

..

Making concept syntax more consistent with class interfaces would not
help programmers understand concepts any better. It may reduce initial
anxiety, because concepts would look like object-oriented interfaces,
but the resemblance would only be skin-deep. Concepts support a
different programming paradigm---Generic Programming---and much of the
confusion I've seen about concepts comes from attempts to think of
them in object-oriented terms. New ideas and constructs should have
new syntax, to emphasize that they are different from existing ideas/
constructs. Sometimes syntactic similarity can be a good thing, but
not when it leads to many incorrect assumptions.

..

You have made this argument repeatedly, but without a reference or
explaination as to why GP and OO are so distinct that it's
necessary to add otherwise unnecessary complexity to the syntax of
C++ to play up the difference.

SmallTalk, unlike C++, does not have specific features to support
GP. But I have not seen or heard of a C++ template which cannot
be written in SmallTalk in an equally general way. Do you know
of such an example, or why this is not relevant?

If the premise that OO and GP are "merged" in SmallTalk cannot
be refuted, that would indicate the choice between
class hierarchies with virtual functions and templates in
C++ has more to do with practical issues like "do I want
to reuse object as well as source?", "is it reasonable
to add a new base class to classes I want to use this
code with?", "does the code need to create non-dynamic
instances of objects of non-specific type?".

Of course, SmallTalk does not need to deal with the
issue of non-dynamic objects (there aren't any). But
that seems pretty lame as a significant reason
we need an entirely distinct programming "paradigm"
in C++.

(If I need to understand exactly what the word
"paradigm" means in order to understand the
distinction between GP and OO, you all can give
up on me right now.)

If the distinction between OO and GP is only
meaningful in a certain type of programming
language, that would seem a reason to play
down rather than up the difference.

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

[Douglas Gregor]

On Mar 5, 7:55 pm, "W Karas" <wka...@yahoo.c omwrote:

On Mar 5, 1:02 pm, "Douglas Gregor" <doug.gre...@gm ail.comwrote:On Mar 5, 9:12 am, "W Karas" <wka...@yahoo.c omwrote:
.

Making concept syntax more consistent with class interfaces would not
help programmers understand concepts any better. It may reduce initial
anxiety, because concepts would look like object-oriented interfaces,
but the resemblance would only be skin-deep. Concepts support a
different programming paradigm---Generic Programming---and much of the
confusion I've seen about concepts comes from attempts to think of
them in object-oriented terms. New ideas and constructs should have
new syntax, to emphasize that they are different from existing ideas/
constructs. Sometimes syntactic similarity can be a good thing, but
not when it leads to many incorrect assumptions.

.

You have made this argument repeatedly, but without a reference or
explaination as to why GP and OO are so distinct that it's
necessary to add otherwise unnecessary complexity to the syntax of
C++ to play up the difference.

There is a short write-up of the differences (at a feature level)
here:

http://www.generic-programming.org/f...ed-programming

SmallTalk, unlike C++, does not have specific features to support
GP. But I have not seen or heard of a C++ template which cannot
be written in SmallTalk in an equally general way. Do you know
of such an example, or why this is not relevant?

Well, one obvious answer is any example of the Binary Method Problem.
Say you have some Shape interface and you want to be able to compare
Shapes with an isEqual method... I'll write it in Java, because I'm
less likely to mangle the syntax:

interface Shape {
boolean isEqual(Shape other);
}

Now, a Triangle is a Shape:

class Triangle implements Shape {
private int base;
private int height;

public boolean isEqual(Triangl e other)
{
return base == other.base && height == other.height;
}
}

In Java, this doesn't work and the compiler will complain because
Triangle's isEqual takes a Triangle whereas Shape's isEqual accepts a
shape. To get around Java's static type system, we use explicit casts
and write Triangle's isEqual like this:

public boolean isEqual(Shape other_shape)
{
Triangle other = (Triangle)other _shape;
return base == other.base && height == other.height;
}

Similarly, we can define a Circle that also implements Shape and has
its own isEqual method. We can then trigger a run-time error by trying
to compare a Circle to a Triangle:

Shape a = new Triangle(...);
Shape b = new Circle(...);
a.isEqual(b); // exception: run-time cast failed

Here's one of the earlier discussions of the binary method problem in
Smalltalk, which focuses on the double-dispatching issue: if you have
different kinds of graphical objects, and different kinds of display
ports, how can you write methods that display each kind of graphical
objects differently on each display port?

http://portal.acm.org/citation.cfm?id=28732

In the concepts world, Shape would be a concept with an isEqual
function, e.g.,

concept Shape<typename T{
bool isEqual(T, T);
}

Note that we're using parametric polymorphism to describe concepts,
not subtype polymorphism: that's problem the single, most important
theoretical difference between OO and GP.

To say that Triangle is a Shape, we write an externally-defined
concept map:

concept map Shape<Triangle{
bool isEqual(Triangl e a, Triangle b) {
return a.base == b.base && a.height == b.height;
}
}

We would do the same for Circle.
The static type system prevents us from ever getting into trouble with
isEqual: Triangle meets the requirements of Shape, and Circle meets
the requirements of Shape, but that does not imply anything about the
relationship between Triangle and Circle. For example:

template<typena me T>
where Shape<T>
bool equal_shapes(T a, T b) {
return isEqual(a, b);
}

Triangle a;
Circle b;
equal_shapes(a, b); // compile-time error: T=Triangle in first arg,
T=Circle in second arg.

Parametric polymorphism, as in templates, retains the identity of
types. Subtype polymorphism, as in object-oriented languages, loses
type identity. To write the equivalent of the Java Shape's isEqual
method with parametric polymorphism in a constrained template, we'd
effectively be saying:

template<typena me T, typename U>
where Shape<T&& Shape<U>
bool equal_shapes2(T a, U b) {
return isEqual(a, b);
}

The real types T and U vary independently, but both are Shapes. When
this is done in a OO world, the type-checking is pushed to run time,
inside the body of isEqual (whose interface says that *any* two shapes
can be compared). In a GP world (and with C++ concepts), the isEqual
call inside equal_shapes2 would fail at compile time: the Shape
concept says that a T can be compared with itself, rather than saying
that it can be compared against any Shape.

If you want to say that any Shape can be compared against any other
Shape (say, in a hasSameArea function), you would use more parametric
polymorphism:

concept ShapeWithArea<t ypename T: Shape<T{
double area(T);

template<typena me Uwhere Shape<Ubool hasSameArea(T, U);
}

Cheers,
Doug

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

[Grizlyk]

Douglas Gregor wrote:

>
Making concept syntax more consistent with class interfaces would not
help programmers understand concepts any better. It may reduce initial
anxiety, because concepts would look like object-oriented interfaces,
but the resemblance would only be skin-deep. Concepts support a
different programming paradigm---Generic Programming---and much of the
confusion I've seen about concepts comes from attempts to think of
them in object-oriented terms. New ideas and constructs should have
new syntax, to emphasize that they are different from existing ideas/
constructs. Sometimes syntactic similarity can be a good thing, but
not when it leads to many incorrect assumptions.

Where can one easy learn concept syntax and semantics?
--
Maksim A. Polyanin
http://grizlyk1.narod.ru/cpp_new

"In thi world of fairy tales rolls are liked olso"
/Gnume/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:st*****@ ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

[Douglas Gregor]

On Mar 6, 12:41 pm, grizl...@yandex .ru ("Grizlyk") wrote:

Douglas Gregor wrote:

Making concept syntax more consistent with class interfaces would not
help programmers understand concepts any better. It may reduce initial
anxiety, because concepts would look like object-oriented interfaces,
but the resemblance would only be skin-deep. Concepts support a
different programming paradigm---Generic Programming---and much of the
confusion I've seen about concepts comes from attempts to think of
them in object-oriented terms. New ideas and constructs should have
new syntax, to emphasize that they are different from existing ideas/
constructs. Sometimes syntactic similarity can be a good thing, but
not when it leads to many incorrect assumptions.

Where can one easy learn concept syntax and semantics?

There are a few ways to learn about concepts. The latest concepts
proposal provides an introduction to concepts:

http://www.open-std.org/jtc1/sc22/wg...2006/n2081.pdf

Or, you can watch a Google Tech Talk I gave a few weeks ago that
provides yet another introduction to concepts:

http://video.google.com/videoplay?do...14981047186825

Finally, since there is no substitute for trying out a feature
yourself, you can take what you've learned from one of the above and
try it with ConceptGCC, our prototype implementation:

http://www.generic-programming.org/software/ConceptGCC/

Cheers,
Doug

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

[W Karas]

On Mar 6, 9:38 am, "Douglas Gregor" <doug.gre...@gm ail.comwrote:

On Mar 5, 7:55 pm, "W Karas" <wka...@yahoo.c omwrote:

On Mar 5, 1:02 pm, "Douglas Gregor" <doug.gre...@gm ail.comwrote:On Mar 5, 9:12 am, "W Karas" <wka...@yahoo.c omwrote:
.

Making concept syntax more consistent with class interfaces would not
help programmers understand concepts any better. It may reduce initial
anxiety, because concepts would look like object-oriented interfaces,
but the resemblance would only be skin-deep. Concepts support a
different programming paradigm---Generic Programming---and much of the
confusion I've seen about concepts comes from attempts to think of
them in object-oriented terms. New ideas and constructs should have
new syntax, to emphasize that they are different from existing ideas/
constructs. Sometimes syntactic similarity can be a good thing, but
not when it leads to many incorrect assumptions.

.

You have made this argument repeatedly, but without a reference or
explaination as to why GP and OO are so distinct that it's
necessary to add otherwise unnecessary complexity to the syntax of
C++ to play up the difference.

There is a short write-up of the differences (at a feature level)
here:

http://www.generic-programming.org/f...gms#object-ori...

SmallTalk, unlike C++, does not have specific features to support
GP. But I have not seen or heard of a C++ template which cannot
be written in SmallTalk in an equally general way. Do you know
of such an example, or why this is not relevant?

Well, one obvious answer is any example of the Binary Method Problem.
Say you have some Shape interface and you want to be able to compare
Shapes with an isEqual method... I'll write it in Java, because I'm
less likely to mangle the syntax:

interface Shape {
boolean isEqual(Shape other);
}

Now, a Triangle is a Shape:

class Triangle implements Shape {
private int base;
private int height;

public boolean isEqual(Triangl e other)
{
return base == other.base && height == other.height;
}
}

In Java, this doesn't work and the compiler will complain because
Triangle's isEqual takes a Triangle whereas Shape's isEqual accepts a
shape. To get around Java's static type system, we use explicit casts
and write Triangle's isEqual like this:

public boolean isEqual(Shape other_shape)
{
Triangle other = (Triangle)other _shape;
return base == other.base && height == other.height;
}

Similarly, we can define a Circle that also implements Shape and has
its own isEqual method. We can then trigger a run-time error by trying
to compare a Circle to a Triangle:

Shape a = new Triangle(...);
Shape b = new Circle(...);
a.isEqual(b); // exception: run-time cast failed

Here's one of the earlier discussions of the binary method problem in
Smalltalk, which focuses on the double-dispatching issue: if you have
different kinds of graphical objects, and different kinds of display
ports, how can you write methods that display each kind of graphical
objects differently on each display port?

http://portal.acm.org/citation.cfm?id=28732

In the concepts world, Shape would be a concept with an isEqual
function, e.g.,

concept Shape<typename T{
bool isEqual(T, T);
}

Note that we're using parametric polymorphism to describe concepts,
not subtype polymorphism: that's problem the single, most important
theoretical difference between OO and GP.

To say that Triangle is a Shape, we write an externally-defined
concept map:

concept map Shape<Triangle{
bool isEqual(Triangl e a, Triangle b) {
return a.base == b.base && a.height == b.height;
}
}

We would do the same for Circle.

The static type system prevents us from ever getting into trouble with
isEqual: Triangle meets the requirements of Shape, and Circle meets
the requirements of Shape, but that does not imply anything about the
relationship between Triangle and Circle. For example:

template<typena me T>
where Shape<T>
bool equal_shapes(T a, T b) {
return isEqual(a, b);
}

Triangle a;
Circle b;
equal_shapes(a, b); // compile-time error: T=Triangle in first arg,
T=Circle in second arg.

Parametric polymorphism, as in templates, retains the identity of
types. Subtype polymorphism, as in object-oriented languages, loses
type identity. To write the equivalent of the Java Shape's isEqual
method with parametric polymorphism in a constrained template, we'd
effectively be saying:

template<typena me T, typename U>
where Shape<T&& Shape<U>
bool equal_shapes2(T a, U b) {
return isEqual(a, b);
}

The real types T and U vary independently, but both are Shapes. When
this is done in a OO world, the type-checking is pushed to run time,
inside the body of isEqual (whose interface says that *any* two shapes
can be compared). In a GP world (and with C++ concepts), the isEqual
call inside equal_shapes2 would fail at compile time: the Shape
concept says that a T can be compared with itself, rather than saying
that it can be compared against any Shape.

If you want to say that any Shape can be compared against any other
Shape (say, in a hasSameArea function), you would use more parametric
polymorphism:

concept ShapeWithArea<t ypename T: Shape<T{
double area(T);

template<typena me Uwhere Shape<Ubool hasSameArea(T, U);
}

Cheers,
Doug

I feel what you are saying here can be summarized as: When using
templates, names are bound to specific types at compile time. When
using OO, names may not be bound to specific types until runtime.
Unsurprisingly, any binding errors will occur when the binding occurs.

Late binding is generally bad for performance and (I and probably you
and others would agree) for understandabili ty. But it's more
flexible.
Generic algorithms meant for heterogeneous types work better with late
bindings, a benefit which is the mirror image of the "problem" you
show above.

Another way to address multiple dispatch in a way more similar to
C++ OO is to think of the function as a "member" of an implied
class that is the tuple of the types of the function parameters.

Is ultimately the key difference between GP and OO the fact
that member functions are central to OO but not to GP? To
me, member functions seem more central to encapsulation than
polymorphism. It seems easy to conceive of a programming
language with runtime polymorphism but no membership, where
vptrs are passed as hidden function paramaters rather than
being hidden object data members. With this approach,
multiple dispatch becomes easy -- there is a vptr hidden
parameter for each "polymorphi c type tuple" rather than
just for each polymorphic type.

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

[jam]

On Mar 6, 6:38 pm, "Douglas Gregor" <doug.gre...@gm ail.comwrote:

On Mar 5, 7:55 pm, "W Karas" <wka...@yahoo.c omwrote:

On Mar 5, 1:02 pm, "Douglas Gregor" <doug.gre...@gm ail.comwrote:On Mar 5, 9:12 am, "W Karas" <wka...@yahoo.c omwrote:
.

Making concept syntax more consistent with class interfaces would not
help programmers understand concepts any better. It may reduce initial
anxiety, because concepts would look like object-oriented interfaces,
but the resemblance would only be skin-deep. Concepts support a
different programming paradigm---Generic Programming---and much of the
confusion I've seen about concepts comes from attempts to think of
them in object-oriented terms. New ideas and constructs should have
new syntax, to emphasize that they are different from existing ideas/
constructs. Sometimes syntactic similarity can be a good thing, but
not when it leads to many incorrect assumptions.

.

You have made this argument repeatedly, but without a reference or
explaination as to why GP and OO are so distinct that it's
necessary to add otherwise unnecessary complexity to the syntax of
C++ to play up the difference.

There is a short write-up of the differences (at a feature level)
here:

http://www.generic-programming.org/f...gms#object-ori...

SmallTalk, unlike C++, does not have specific features to support
GP. But I have not seen or heard of a C++ template which cannot
be written in SmallTalk in an equally general way. Do you know
of such an example, or why this is not relevant?

Well, one obvious answer is any example of the Binary Method Problem.
Say you have some Shape interface and you want to be able to compare
Shapes with an isEqual method... I'll write it in Java, because I'm
less likely to mangle the syntax:

interface Shape {
boolean isEqual(Shape other);
}

Now, a Triangle is a Shape:

class Triangle implements Shape {
private int base;
private int height;

public boolean isEqual(Triangl e other)
{
return base == other.base && height == other.height;
}
}

In Java, this doesn't work and the compiler will complain because
Triangle's isEqual takes a Triangle whereas Shape's isEqual accepts a
shape. To get around Java's static type system, we use explicit casts
and write Triangle's isEqual like this:

public boolean isEqual(Shape other_shape)
{
Triangle other = (Triangle)other _shape;
return base == other.base && height == other.height;
}

Similarly, we can define a Circle that also implements Shape and has
its own isEqual method. We can then trigger a run-time error by trying
to compare a Circle to a Triangle:

Shape a = new Triangle(...);
Shape b = new Circle(...);
a.isEqual(b); // exception: run-time cast failed

Here's one of the earlier discussions of the binary method problem in
Smalltalk, which focuses on the double-dispatching issue: if you have
different kinds of graphical objects, and different kinds of display
ports, how can you write methods that display each kind of graphical
objects differently on each display port?

http://portal.acm.org/citation.cfm?id=28732

In the concepts world, Shape would be a concept with an isEqual
function, e.g.,

concept Shape<typename T{
bool isEqual(T, T);
}

Note that we're using parametric polymorphism to describe concepts,
not subtype polymorphism: that's problem the single, most important
theoretical difference between OO and GP.

To say that Triangle is a Shape, we write an externally-defined
concept map:

concept map Shape<Triangle{
bool isEqual(Triangl e a, Triangle b) {
return a.base == b.base && a.height == b.height;
}
}

We would do the same for Circle.

The static type system prevents us from ever getting into trouble with
isEqual: Triangle meets the requirements of Shape, and Circle meets
the requirements of Shape, but that does not imply anything about the
relationship between Triangle and Circle. For example:

template<typena me T>
where Shape<T>
bool equal_shapes(T a, T b) {
return isEqual(a, b);
}

Triangle a;
Circle b;
equal_shapes(a, b); // compile-time error: T=Triangle in first arg,
T=Circle in second arg.

Parametric polymorphism, as in templates, retains the identity of
types. Subtype polymorphism, as in object-oriented languages, loses
type identity. To write the equivalent of the Java Shape's isEqual
method with parametric polymorphism in a constrained template, we'd
effectively be saying:

template<typena me T, typename U>
where Shape<T&& Shape<U>
bool equal_shapes2(T a, U b) {
return isEqual(a, b);
}

The real types T and U vary independently, but both are Shapes. When
this is done in a OO world, the type-checking is pushed to run time,
inside the body of isEqual (whose interface says that *any* two shapes
can be compared). In a GP world (and with C++ concepts), the isEqual
call inside equal_shapes2 would fail at compile time: the Shape
concept says that a T can be compared with itself, rather than saying
that it can be compared against any Shape.

If you want to say that any Shape can be compared against any other
Shape (say, in a hasSameArea function), you would use more parametric
polymorphism:

concept ShapeWithArea<t ypename T: Shape<T{
double area(T);

template<typena me Uwhere Shape<Ubool hasSameArea(T, U);
}

Cheers,
Doug

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

- Show quoted text -

Do you mean that refinement syntax is not orignated from that of
inheritance and will not confuse every one?

- It again mixes object-oriented and generic programming ideas in a
way that will lead to confusion. I guarantee that, after showing an
example like the above to an audience, I will get two questions: (1)
why can't I just use ':' to inherit from C? and (2) can I declare a
variable of type C*? Neither question would arise without the
assumption that concepts are just another take on object-oriented
programming (they aren't), and we need to be very careful not to give
the impression that they are.

enerything has a price .For innovation yuo have to be braver than
this. Is the fear that programers might misunderstand a reason for us
not to do anything?.
but there exists one reason for not using concept keyword in that
manor (if I am not mistaken) :concepts allow use of a type when
afeature is available and accesible and ban otherwise but what we need
here is that we want to remind ourselves not to forget to provide a
specific interface for a class currently declared but not defined.I
suggest the 'interface' keyword syntax similar to that of 'concept'
for this porpuse that unlike JAVA will not necessarily mean a runtime
polymorphism.I would like to wrote:

interface CC<typename T>{
public:
T(T&);
private:
void go();
virtual void gogo();
};

CC struct my_type{
/*definition of following functons is a must now and copy-ctor must
not be banned(private or protected).
private: void go();
private: virtual void gogo();
*/
};
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:st*****@ ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]