Concepts

[Matt Calabrese]

Does Clay plan on having a concepts feature (and perhaps something like concept maps)? I just discovered the language and I'm really liking the design so far, but some kind of concept specification in the language would be extremely useful.

[Joe Groff]

I think the C++ concepts proposal is a bit overly complex, but I'd
like to have something like Haskell's type classes or Scala's traits.
You can somewhat approximate the use of concepts for overloading using
predicates, though it's not pretty, and you can also specify an
interface for a generic function at definition time, which behaves
somewhat like a one-member type class:

[T | Number?(T)] define add(x:T, y:T) : T;

`add` will then only be overloadable for `Number?` types.

-Joe

[Matt Calabrese]

On Friday, September 14, 2012 1:16:51 PM UTC-4, Joe Groff wrote:

I think the C++ concepts proposal is a bit overly complex, but I'd
like to have something like Haskell's type classes or Scala's traits.

What specifically about it do you find overly complex? Yes, I am imagining something like the proposed C++ concepts (of which I am deeply familiar), though I wasn't really referring to the proposed C++ concepts. All I mean is a facility that lets you create a generic programming concept with (loose) pseudo-signatures for associated function mapping, concept refinement, associated types, concept-based overloading, and preferably explicit and implicit concept mapping. What do you like better about type classes, and again, what specifically do you not like in the C++ concepts proposal.

[Joe Groff]

On Fri, Sep 14, 2012 at 10:28 AM, Matt Calabrese <riv...@gmail.com> wrote:
> What specifically about it do you find overly complex? Yes, I am imagining
> something like the proposed C++ concepts (of which I am deeply familiar),
> though I wasn't really referring to the proposed C++ concepts. All I mean is
> a facility that lets you create a generic programming concept with (loose)
> pseudo-signatures for associated function mapping, concept refinement,
> associated types, concept-based overloading, and preferably explicit and
> implicit concept mapping. What do you like better about type classes, and
> again, what specifically do you not like in the C++ concepts proposal.

Well, this is all admittedly my own prejudice:
- Functional dependencies are more appealing to me than associated types
- Implicit vs. explicit concept mapping seems like a backward
compatibility aid more than a desirable feature. If you're starting
from a clean slate, I think explicit concept maps are preferable.
- The C++ proposal also proposes concept-dependent lookup, which I'm
not a fan of. I'd prefer that f(T) mean the same thing everywhere, and
not have a special meaning for concept templates.

Beyond that, I agree that associated function mapping, refinement, and
concept-based overloading are all desirable features.

-Joe

[Matt Calabrese]

On Friday, September 14, 2012 7:21:02 PM UTC-4, Joe Groff wrote:

On Fri, Sep 14, 2012 at 10:28 AM, Matt Calabrese <riv...@gmail.com> wrote:
> What specifically about it do you find overly complex? Yes, I am imagining
> something like the proposed C++ concepts (of which I am deeply familiar),
> though I wasn't really referring to the proposed C++ concepts. All I mean is
> a facility that lets you create a generic programming concept with (loose)
> pseudo-signatures for associated function mapping, concept refinement,
> associated types, concept-based overloading, and preferably explicit and
> implicit concept mapping. What do you like better about type classes, and
> again, what specifically do you not like in the C++ concepts proposal.

Well, this is all admittedly my own prejudice:
- Functional dependencies are more appealing to me than associated types

I don't see how it's one or the other. The notion of concepts, and the C++ implementation of them, effectively has them both.

- Implicit vs. explicit concept mapping seems like a backward
compatibility aid more than a desirable feature. If you're starting
from a clean slate, I think explicit concept maps are preferable.

I don't agree, although I do agree that IF for some reason there is only to be one kind, it should be explicit (though ironically, the opposite philosophy is the straw that broke the camel's back for concepts that would have been in C++11, as Stroustrup at the end decided that he wanted all concepts to be auto... what will happen for the next standard will be interesting). Auto concepts (concepts with implicit concept maps) are really useful, especially for simple concepts such as many of the ones that were proposed for the C++ standard library, such as the std::HasOperator family of concepts, the n-ary std::Predicate concept for types that were callable with a given set of parameter types and whose result was convertible to bool, etc. Having to explicitly state that you are modeling many of these concepts, especially the HasOperator family, in some ways defeats their purpose. Being able to use their associated result_type and have it be automatically deduced is also very useful.

The way I see it, explicit concepts are good for concepts with properties that can't be checked by the compiler, and so require a programmer to offer a little help -- for instance, a concept that describes a binary operation that is commutative (a compiler can't reasonably detect that some arbitrarily complex user-defined function is a commutative operation). Auto concepts are also great as building-blocks for higher-level explicit concepts (for instance, a type may require being additive and commutative, in which case it can refine HasPlus with the appropriate parameters with additional requirements and an axiom specifying commutativity).

- The C++ proposal also proposes concept-dependent lookup, which I'm
not a fan of. I'd prefer that f(T) mean the same thing everywhere, and
not have a special meaning for concept templates.

While I agree that it is unfortunate that it is like that, in some sense, I'm not sure what the alternative would be when in the presence of concept maps. How else would the mapped information be interfaced with in a template whose types are constrained by concepts? Would you have to always explicitly qualify via something like SomeConcept< your_type >::operator +( left, right ) /*C++ syntax since I'm more familiar with that*/? Or do you mean that the associated functions should always be usable everywhere without qualification and make it so that the associated functions are required to be found by ordinary look-up rules in order for the concept to be modeled? 

[Joe Groff]

Hi Matt. Jeremy Clifford and I are currently discussing a design for
type classes near the end of
https://github.com/jckarter/clay/pull/375, if you would like to
contribute.

-Joe