Re: [boost] Provisional Boost.Generic and Boost.Auto_Function (concepts without concepts)

Subject: Re: [boost] Provisional Boost.Generic and Boost.Auto_Function (concepts without concepts)
From: Matt Calabrese (rivorus_at_[hidden])
Date: 2010-12-15 15:48:31

On Wed, Dec 15, 2010 at 2:07 PM, Dave Abrahams <dave_at_[hidden]> wrote:

> I have some concerns over the use of valid expressions rather than
> pseudosignatures; they tend to make it very difficult to write correct
> algorithms.
>

I'm not sure I immediately understand your concerns, so please elaborate.
For what it's worth, I do plan on eventually supporting pseudosignatures,
though the macro will internally translate the pseudosignature to their
corresponding "expression validity check" anyway (but with the added benefit
of more likely being able to be translated directly to what may be C++1x
concept pseudosignatures, though this is not really my concern for now). The
reason I didn't take this approach from the start is it is much more
complicated to preprocess a pseudosignature parameter -- in particular, I'd
need special handling of operators (I.E. users would have to spell
operator++ as operator pre_inc and the macro internally would have to handle
each operator explicitly, which will be a fairly tedious undertaking). If
you can explain what exactly you feel is problematic with the current
approach in more detail I have no problem with eventually scrapping the
current interface and only supporting pseudosignatures instead.

Can you create archetypes from these concept definitions
> and do compile-time checking of algorithm bodies?  Have you tried to
> (re-)write any interesting algorithms using these concepts?

As for archetypes do you mean automatically create archetypes? If so, then
no. Is this the problem you see with the "valid expression" approach over
pseudosignatures? I'd imagine that with pseudosignatures it may be possible
for me to automatically generate archetypes, though I'd have to give it
further thought. That alone is certainly a convincing argument for
pseudosignatures, however, I can see the macro getting fairly complicated if
such functionality is to be fully-featured. If I do eventually follow that
idea, it will likely take quite some time to implement.

As for writing algorithms with the concepts, no, I haven't done so yet other
than an Auto_Function "advance" that uses concept-based overloading.
Unfortunately, things end up being verbose and loaded with parentheses.
Manual tag dispatching ends up being cleaner in practice, so the benefits
are questionable. The main advantage here is that such "category" types that
are used for tag dispatching don't have to be created to begin with since
the concepts themselves can be used directly. Here's the "advance"
implementation I use for testing. It is actually much more complicated than
std::advance because I'm using the return type to determine which overload
is picked. Try to look past that complexity since it wouldn't be there in an
actual implementation.

http://codepaste.net/qcz4cq

Anyway, at the moment such rewrites aren't very interesting except for being
able to do concept-based overloads, since currently the only concept maps
that are supported are empty concept maps. With regards to the iterator
concepts, associated types are still accessed via iterator_traits as opposed
to via a concept_map directly because I have yet to fully implement
associated types with concept maps. So, at this point, Generic is really
only worthwhile for "pretty" asserts and concept-based overloading, though
that should hopefully change in the near future.

-- 
-Matt Calabrese