Proposal to add 'Elements of Programming' Concepts to std.traits

[Andrei Alexandrescu]

On 6/17/12 4:47 PM, Guillaume Chatelet wrote:
> On 06/17/12 18:38, Andrei Alexandrescu wrote:
>> However, I don't think we need to abide strictly to the nomenclature
>> (e.g. some of the stuff in EoP was already defined with a different
>> name) although some EoP names are more mathematicky (such as "Codomain"
>> vs. "ReturnType"). One issue is when EoP goes off and defines its own
>> terms such as "regular type", which is usually known as "value type". In
>> fact, "regular type" means something completely different in PL
>> research. EoP's terminology didn't catch up outside C++ and sometimes
>> outside a small group within it.
>
> Yes. As you noticed CoDomain is simply an alias to ReturnType.
>
> The purpose of this thread was to measure the interest of the D
> community in going further in this direction. I thought it would be
> great to benefit from the work the C++ community has already done in
> this domain. Brilliant people are working on it for years and the more
> basic Concepts look stable now so it might be a good starting point.

That's great. On the other hand D is not C++, and it naturally fosters a 
different dynamics of idioms.

D has static if and restricted templates, which are the concept 
equivalent of lambda functions. That changes the play field considerably 
because in C++ the syntactic overhead of expressing any constraint is so 
high, the normal tendency is to name everything. In D, you only need to 
name things that are often used and relatively complex.

So I don't think copying the laundry list of C++ concepts is the best 
way to go, because some of those overcome insufficiencies that are 
obviated by D.

Nevertheless, a good design is a good design, and we could and should 
use is as inspiration.

> My take on it is that Concept modeling improves in designing and
> extending complex generic libraries. As an example see the Generic Image
> Library (GIL) by Adobe and now part of Boost.
> http://stlab.adobe.com/gil/html/gildesignguide.html
>
> Of course, the idioms being different, I was also looking for some
> feedback. I did ask myself what naming convention should be used
> considering some traits were already implemented as you pointed out. I
> sticked to the D _isXXXX_ convention instead of the plain CamelCase
> name.

I think either way is fine. One convention I tried to foster was to name 
all symbols that ultimately expand to values starting with a lowercase, 
e.g. isXXX or hasXXX, and symbols that ultimately yield non-values 
should start with an uppercase, e.g. Unsigned or Unqual.

> I was tempted to use a _hasValueSemantic_ traits (Concept) instead
> of _isRegular_.

I personally would love that. Honest I think isRegular is provincial. 
Just google for "regular type" to see what I mean.

> Also _isPure_ could replace _isFunctionalProcedure_.
> Basically this is just a proposal and everything can change at this
> point. I'm also not convinced we should add every single Concepts
> Stepanov is describing, we have to be pragmatic here.

Awesome, my thoughts above (written before I saw this paragraph) reflect 
the same view.

> So what do you think should be the next move ? Try to integrate those
> concepts within phobos ? try to add more of them ?
>
> More comments are definitely welcome. Many thanks for everyones feedback.

I think traits are something that we could add piecemeal, without a 
large proposal - just as pull requests. For each particular concept 
there should be 1-2 compelling examples in the documentation, enough to 
make a case that the notion being added is worthwhile.

For a simple example I'd like "arity" (I'm unclear whether it belongs in 
std.traits or std.functional). Sure, I could write 
ParameterTypeTuple!fun.length, but that's quite a roundabout way to go 
about it.


Andrei