concept primitives?

[rnburn]

Have you thought of including some basic primitive concepts? like those defined in "Elements of Programming" and similar to what will be in concepts-lite

[pfultz2]

It seems like a good idea, especially the concepts used in C++ here. Of course there is no need to define them for concepts like DefaultConstructible since it is already provided by C++ standard library.

[jeremy-murphy]

I wonder if the OP was referring to the algebraic concepts, which Peter Gottschling also detailed in TR638 back in 2006. I stayed started playing around with algebraic traits for Boost.Math but perhaps this is a more logical place to try it out.

[viboes]

I believe that the concepts must be added by the library that use them. Adding concepts that no library use is a lost of time IMHO. Another this is having some of those concepts implemented as examples to check the usability of the library.

[jeremy-murphy]

Sure, that makes sense, assuming you mean things like graph concepts are in the Boost.Graph library, etc? What do we consider as 'standard' concepts, i.e. deserving of being in the C++ standard library or at least built-in to a concept-checking library? E.g. iterator concepts, algebraic concepts, etc.

[viboes]

I admit that the library could provide the C++ standard library requirements as Tick constraints as we can not have them on the C++ standard library.

What algebraic concepts would you like to have?

[jeremy-murphy]

The ones defined in Elements of Programming and also in TR638, which I mentioned above: magma, monoid, ring, field, group, module, etc.

On a side note, I would also like algebraic traits of types in a similar style to std::numeric_traits, e.g. algebraic_traits<BinaryOp>::is_commutative() and algebraic_traits<BinaryOp>::zero_element(), but I'm not sure if that's a separate conversation. The traits seem like a building block of the concepts, though, right?

[jeremy-murphy]

Any more thoughts on this? I'm quite interested in following it up.

[pfultz2]

The tick library is focused on syntactic-based concepts like the ones defined in the Concepts TS. To support the algebraic_traits the library would need more semantic-based concepts, and a framework for handling those type of concepts.

I think semantic-based concepts would be very useful. The library could definitely grow to support them, which the library would expand beyond just a concepts traits library to supporting a full-range of concepts. Although, I haven't fully thought about the best way to define semantic-based concepts in a library and how they interact with syntactic concepts, but I imagine it would be close to how hana defines its type classes. This is definitely an interesting area to explore.

[viboes]

I agree that semantic-based concepts needs either well established practice or explicit mapping, as Hana does. I believe that this is out of the scope of the library.

[jeremy-murphy]

I made a primitive implementation of algebraic traits here just as a proof-of-concept. I'm no expert on template metaprogramming so please don't be horrified by any egregious shortcomings in my code. But the basic example is accumulate_if, which terminates if the binary operation being applied results in the zero element for that operation. Which in the case of gcd is 1.

[pfultz2]

So initial documentation for the traits provided by the library has been added here. This should cover the basic concept primitives.

[robertramey]

The document includes a nice page for documenting is_forward_iterator. That page suggests that the header exists:

#include <tick/traits/is_forward_iterator.h>

But I find no such header in the package. What's up with this?

[pfultz2]

But I find no such header in the package. What's up with this?

The file is here. I am not sure why it missing for you. Its there when I clone it from github.