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
