Re: [boost] data_binding library for boost... Any interest?

From: Larry Evans (cppljevans_at_[hidden])
Date: 2008-07-26 10:06:13

On 07/22/08 15:07, Brook Milligan wrote:
> Stjepan Rajko writes:
>  > I have tried to tackle the value/domain transformation problem a while
>  > back, inspired by Brook Milligan's (CC-d) probability library (which
>  > can nicely transition probability values between linear and log
>  > domains).
> 
>  > Brook Milligan also worked on a generic domain transformation library,
>  > so he might comment on this as well.  There is also the Boost.Units
>  > library which might offer transformations for some cases.
> 
> Thanks, Stjepan.  I've continued to refactor that, actually, to make
> it support the more generic problem under discussion here.  So far it
> is mostly done.  I think the only issues are some silly overloading
> resolution issues that have little to do with the basic ideas.  For
> the discussion I'll outline my approach.
> 
> The basic observation that motivates this is that in some (many?)
> situations there exist a group of related types that clearly have
> common semantics in the application domain but may impose different
> constraints in their implementation.  Indeed, some operations may not
> be practical or feasible for some of the types but could be for others
> and there may exist transformations from one to another.  In the case
> of probabilities think of two types, one for a probability and one for
> its logarithm with appropriate operators defined for each domain and
> the interconversions.  Another example involves the representation of
> polynomials, which can be in terms of coefficients or in spectral
> terms that ease their multiplication.  In this case, it may be
> completely undesirable to implement a polynomical multiplication for
> the coefficient representation.
> 
> Conceptually then, the Domain library seeks to create a framework for
> implementing sets of such types that work smoothly together, and
> enable the compiler to make choices about how to handle mixed domain
> operations (e.g., adding a probability and a log probability) or
> operations that must be performed in another domain (e.g., multiplying
> two polynomials represented as coefficients).  I think these are most
> of the salient points, all of which are currently supported.
> 
> - Allow definition of families of types (domains) based upon each
>   member of a family sharing common semantics in the application
>   domain.
> 
> - Allow implementation (or not) of any within-domain operators that
>   make sense in the application domain.
> 
> - Allow implementation (or not) of any appropriate interdomain type
>   transformations.
> 
> - Decouple the domain type information from the value types used to
>   represent the internal domain-specific information.
> 
> - Allow specification of a default value type for any domain type so
>   that unspecified templates (i.e., T<>) provide meaningful results.
> 
> - Allow specification of which domains are interconvertible as a
>   series of pairwise conversions.
> 
> - Allow specification of which domains support which operations so
>   that the compiler can seek an appropriate domain for arguments that
>   may (or may not) be directly usable.
> 
[snip]
In this thread, there's frequent mention of domains, and groups of
related types and transformations between domains.  Thes phrases
remind me of proto's transformations:

http://boost-sandbox.sourceforge.net/libs/proto/doc/html/boost_proto/users_guide/expression_transformation.html

is there any chance proto could be used?

Also, the mention of common set of types and transformations reminds
me of algebras and transformations between those algebras.  In
particular, there was mention of some operators defined for
some domains and not for others.  This reminds me of algebraic
structure that have a limited set of operators.  For example:

http://planetmath.org/encyclopedia/Monoid.html
http://planetmath.org/encyclopedia/Ring.html

and more generally, for any number of operators:

http://planetmath.org/encyclopedia/HomomorphismBetweenAlgebraicSystems.html

The 'group of related types' phrase reminds me of 'many-sorted
algebras' where each sort corresponds to type in 'group of
related types':

http://planetmath.org/encyclopedia/ManySortedStructure.html

Is there any chance the data_binding library is related?
IOW, would the data_binding library dos use some of the
terminology in the above planetmath .htmls to describe
the library's purpose?