Martin Hinsch wrote:

> James Dennett Wrote:
> 
>> janderson wrote:
>> > janderson wrote:
>> >> Martin Hinsch wrote:
>> >>> Inspired by this video (linked by an earlier post, and very interesting; I really hope that D will get something similar)
>> >>>
>> >>> http://video.google.com/videoplay?docid=-1790714981047186825&hl=en
>> >>>
>> >>> I started to think about the relation of concepts and interfaces.
>> >>> In a way both serve very similar purposes, namely supporting
>> >>> polymorphism. The major difference is of course that one is used at
>> >>> compile time and the other one at run-time. Still, in the end both
>> >>> are just a way to describe the constraints which have to be fulfilled
>> >>> by a type in order to be usable in a specific generic way.
>> >>> Interestingly the syntactic differences are nevertheless
>> >>> considerable. My main point in this post is that this is mainly for
>> >>> historical reasons and that it might be beneficial to think about
>> >>> making interfaces and concepts more similar to each other.
>> >>>
>> >>> Some more specific thoughts:
>> >>>
>> >>> - why does conformance to an interface have to be specified
>> >>> explicitly (as in class C implements interface I)? Why not do
>> >>> post-hoc checking as with concepts/templates?
>> >>> Using an object via an interface implies two things - the compiler
>> >>> has to check whether the objects class actually implements all
>> >>> methods required by the interface and the object reference has to be
>> >>> manipulated in such a way that when using it when assigned to an
>> >>> interface reference the right method calls are done. If we assume
>> >>> that all casts from an object to an interface reference are visible
>> >>> at compile time both of these could be done *at the point of the
>> >>> cast* (equivalent to the way type checking is done for template
>> >>> instantiation).
>> >>>
>> >>> - why not make concepts obligatory?
>> >>> One of the beneficial aspects of using interfaces is in my opinion
>> >>> that it forces you to be specific about which properties you expect
>> >>> from the plugged in types. This is something which is missing from
>> >>> generic programming and which is supposed to be improved by
>> >>> introducing concepts. C++ of course has to stay backwards-compatible
>> >>> therefore concepts will be completely optional.
>> >>> In D OTOH concepts could actually be made obligatory forcing the
>> >>> programmer to be explicit about the properties of the types which can
>> >>> be plugged into a template/generic class.
>> >>>
>> >>> - interface_maps
>> >>> With implicit implementation of interfaces the concept_map idea might
>> >>> come in handy for interfaces as well, allowing to do some adjustments
>> >>> to make a class conforming to an interface.
>> >>>
>> >>> Just some food for thought.
>> >>>
>> >>> cheers
>> >>> Martin Hinsch
>> >>
>> >> I'm not sure D necessarily needs to support this the same way as C++. However the C++ developers of concepts are very smart people and have obviously put a lot of thought into this.  We should consider all options.
>> >>
>> >> It would be nice when C++0x comes out we could say, D's had all these features for years.  If your going to switch, why not switch to D.
>> >>
>> >> -Joel
>> > 
>> > 
>> > Just a thought, could concepts possibly be jammed into contracts?
>> > 
>> > void Foo(T)(T t)
>> > in
>> > {
>> >     static assert(IsIterator!(T));
>> > }
>> > body
>> > {
>> > 
>> > }
>> 
>> Not nicely, as concepts are able to affect things
>> like overload resolution; what's wanted if Foo
>> requires IsIterator(T) is not a compile-time error
>> about an assertion failing, but that the function
>> simply drop out of the overload set (so that some
>> other function might match).  At least, that's
>> the C++ way.  Of course D can be Different.
>> 
>> -- James
> 
> Plus, the charme of C++ concepts is that they are completely separate entities with a syntax which is very similar to a class declaration. IMHO that makes it very easy to really think of them as abstract reusable entities which describe a _concept_.

It's like a metaprogramming typesystem, extending type correctness to template code. (hope something like this gets adopted for D)

Martin, I personally feel that properly implementing contract programming would envelop any functionality that you're suggesting; as "concepts" only applies to class-oriented programming, and contracts apply to any methods/functions...

I believe a more flexible, powerful, and wide-reaching modification would be to enhance contracts with proper bounds and type declarations *without* asserts - and to have a compiler option that performs proof by induction (by examining potential upstream flow control paths and tracing them back down to the contract to verify all cases are within bounds.  This may also identify infinite loops and such)

For example, *something* like:

invariant {
  x // is within the realm of 0..int.max - 3
  i < myArray.length;
}
x += 3; // would normally cause an overflow if x is (int.max-3)..int.max

In this way, many kinds of proveable constraints can be performed on information flowing through these constraint blocks at compile time via proof-by-induction; instead of performing asserts/ifs whenever.

Those that can't be proven at compile time could optionally be examined at runtime (asserts/ifs), examined by the programmer to see if they're "going to be reasonable, don't bother checking at runtime" or whatnot.

Implementing this would make code *proveable* which dramatically increases the power of programmers during the debugging cycle such that "what the heck is it doing wrong?" is replaced with "so exactly what am I allowing it to do?"

This may sound a little retarded, but wouldn't making concepts obligatory make generic programming more complex and hence more difficult?  In my opinion this may do more harm than good.  A huge appeal of generic stuff in D is that it's easier to work with than the C++ stuff.  More powerful, yes, but also easier.  IMO this is very important.

On the other hand, this increased complexity is a burden only on the one who is developing the generic library.  It's appeal is that it makes life easier for the developer that uses the generic library because that developer gets more intelligent error messages.  This makes generic libraries more attractive to the average developer.

While I'm not opposed to these features, they don't make me terribly excited.  With all the other features on the queue, I don't forsee anything like this getting into D.

-Craig

Craig Black wrote:
> This may sound a little retarded, but wouldn't making concepts obligatory make generic programming more complex and hence more difficult?  In my opinion this may do more harm than good.  A huge appeal of generic stuff in D is that it's easier to work with than the C++ stuff.  More powerful, yes, but also easier.  IMO this is very important.

Concepts appear to make generic programming simpler and hence easier, with more meaningful diagnostics.

> On the other hand, this increased complexity is a burden only on the one who is developing the generic library.

Developers of generic libraries also tend to use a lot
of generic code; they benefit from the checking as well
as being the ones who provide that benefit to downstream
users.

> It's appeal is that it makes life easier for the developer that uses the generic library because that developer gets more intelligent error messages.  This makes generic libraries more attractive to the average developer.

And for library writers too.

> While I'm not opposed to these features, they don't make me terribly excited.  With all the other features on the queue, I don't forsee anything like this getting into D.

But what about keeping up with the Joneses? ;)

-- James

James Dennett wrote:
> Craig Black wrote:
>> This may sound a little retarded, but wouldn't making concepts obligatory make generic programming more complex and hence more difficult?  In my opinion this may do more harm than good.  A huge appeal of generic stuff in D is that it's easier to work with than the C++ stuff.  More powerful, yes, but also easier.  IMO this is very important.
> 
> Concepts appear to make generic programming simpler and
> hence easier, with more meaningful diagnostics.

But I think Craig's point is valid (and interesting) -- concepts will have a huge benefit for complicated C++ template code, but since D templates are easier to work with already (and we have static if/is/static assert), in D, concepts are at a totally different point on the cost-benefit curve. Are they still worthwhile?

Don Clugston wrote:
> James Dennett wrote:
>> Craig Black wrote:
>>> This may sound a little retarded, but wouldn't making concepts obligatory make generic programming more complex and hence more difficult?  In my opinion this may do more harm than good.  A huge appeal of generic stuff in D is that it's easier to work with than the C++ stuff.  More powerful, yes, but also easier.  IMO this is very important.
>>
>> Concepts appear to make generic programming simpler and hence easier, with more meaningful diagnostics.
> 
> But I think Craig's point is valid (and interesting) -- concepts will have a huge benefit for complicated C++ template code, but since D templates are easier to work with already (and we have static if/is/static assert), in D, concepts are at a totally different point on the cost-benefit curve. Are they still worthwhile?

I don't have enough D experience to speak authoritatively,
but the improvements made to C++ by concepts don't have
much to do with syntax (which is largely where D improves
on C++'s templates).  The big benefits are (a) a compiler
can verify that generic code only uses the interfaces it
intended to use, so that it does not accidentally place
additional burdens on client code, and (b) a compiler can
test from the specified required concepts that template
arguments passed by a client are suitable, and can give
very concrete diagnostics if not.  It would seem to me
that both of these benefits would map directly across to
D, though D's explicit support for metaprogramming would
tend to mean that the error messages it produces in the
absence of concepts are not *as* convoluted as those
generated by significant uses of TMP in C++.

-- James

Don Clugston wrote:

> James Dennett wrote:
>> Craig Black wrote:
>>> This may sound a little retarded, but wouldn't making concepts
>>> obligatory
>>> make generic programming more complex and hence more difficult?  In my
>>> opinion this may do more harm than good.  A huge appeal of generic stuff
>>> in
>>> D is that it's easier to work with than the C++ stuff.  More powerful,
>>> yes,
>>> but also easier.  IMO this is very important.
>> 
>> Concepts appear to make generic programming simpler and hence easier, with more meaningful diagnostics.
> 
> But I think Craig's point is valid (and interesting) -- concepts will have a huge benefit for complicated C++ template code, but since D templates are easier to work with already (and we have static if/is/static assert), in D, concepts are at a totally different point on the cost-benefit curve. Are they still worthwhile?

What would D do to replace concept mapping?  That seems to me to be the most interesting part of c++ concepts.

Neal Becker Wrote:
> What would D do to replace concept mapping?  That seems to me to be the most interesting part of c++ concepts.

I'm not sure if I'm on the mark in suggesting any contracts intended to improve the robustness of a program by imposing additional constraints on the data be implemented as an extension of invariant{}

Since we're still programming algorithms explicitly; compile-time evaluation is trivial to constrain?  (infinite for loops, etc)