RE: [boost] Proposed metaprogramming type system

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-12-17 09:47:07

----- Original Message -----
From: Peter Dimov <pdimov_at_[hidden]>
To: Boost List <boost_at_[hidden]>
Sent: Monday, December 17, 2001 11:23 AM
Subject: [boost] Proposed metaprogramming type system

> Purpose:
>
> * provide a common MPL/Loki subset enabling future compatible evolution of
> the libraries and their eventual acceptance into Boost.
>
> * failing that, provide a common threat for MPL and Loki authors enabling
> their cooperation. ;-)
>
> Synopsis:
>
In the overall this looks excelent!
I 'd like to adopt it.

> namespace mpl
> {
>
> struct missing; // missing argument in a variadic function
>
> struct nil;
> template<class, class> struct pair;
>
> struct _1; // bind/ET placeholders
> struct _2;
> // ...
>
> template<class T, T v> struct ct_value
> {
>     static const T value = v;
> };
>
> template<class T> struct ct_type
> {
>     typedef T type;
> };
>
> }
>
> Type system:
>
> The metaprogramming library operates on types only. Compile-time values
are
> wrapped in ct_value<Type, Value>.
>
> (Rationale: practice shows that attempting to cover compile-time values as
> well results in excessive duplication. ct_value<> is chosen to avoid
having
> separate bool_t, int_t, uint_t, size_t_t and so on.)
>
This is very useful for Borland, since it has so poor non-type template
parameter support.

> The primary data structure is a binary tree represented by pair<Left,
> Right>. The most common special case is the list, defined recursively as:
>
> * nil is a list, called the empty list.
> * pair<F, R> is a list iff R is a list.
>
> No type defined by the library, except ct_type<T>, is guaranteed to have
an
> accessible constructor (or be a complete type) unless stated otherwise.

And ct_value<> ?

> Values that correspond to a type T can be obtained using the expression
> ct_type<T>().
>
> (Rationale: it is not yet clear how should the compile-time subset of C++
> interact with the traditional part of the language. On a conforming
> compiler, the library can be written (and used) in such a way as to not
> assume any specific properties of the types, leaving the door open for
> future evolution.)
>
> ct_type<T>, although compatible with the compile-time function
identity<T>,
> is a separate type with a distinct purpose.
>
> Naming convention:
>
> Identifiers that collide with keywords or other C++ reserved identifiers
are
> prefixed with ct_. Example: ct_if<class Cond, class Then, class
Else>::type.
>
> The result of a compile-time function is obtained using function<A1, ...,
> An>::type.
>
> For convenience, some compile-time functions return compile-time values,
as
> well, obtained via function<A1, ..., An>::value.
>
> Compile-time functions that take a non-type argument are suffixed with
'v'.
> Example: ct_ifv<bool Cond, class Then, class Else>::type.
>
> "Quoted" compile-time functions are suffixed with 'q' and are invoked
using
> the function::template apply<A1, ..., An>::type syntax (on a conforming
> compiler.) Example: ct_ifq.
>
I wonder if suffixing 'v' and 'q' to 'funtion' could look awkard with some
specific functions names...
How about suffixing 'ct' instead:  ctv_if<>, ctq_if<>...

> (Rationale: not perfect, but better than no convention.)
>
> STL iterator idiom compatibility:
>
> A list provides forward iterators. For the list (a1 a2 ... aN), the
iterator
> to its k-th element is (ak ak+1 .. aN). The beyond-the-end iterator is
nil.
>
> Example: the compile-time function find<L, E>::type returns the sublist
> starting with the first occurence of E in L, up to the end of L. The
return
> 'value' can be used as an iterator, or it can be used as a condition in
> ct_if (ct_if considers nil and ct_value<bool, false> to be false,
everything
> else to be true.)
>
>
Great syntesis!

(Maybe I like this so much because I could understand it entirely  :-)

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com