[boost] Re: compile time member detection

From: David Abrahams (dave_at_[hidden])
Date: 2003-11-15 22:25:17

Brian McNamara <lorgon_at_[hidden]> writes:

> On Sat, Nov 15, 2003 at 03:07:40PM -0800, Mat Marcus wrote:
>> FYI: Current spelling of the concept declarations in the usage-pattern 
>> approach (although this) is likely to change:
>> 
>> concept Clonable {
>>    constraints(Clonable c) {
>>        clone(c);
>>    };
>> };
>> 
>> or equivalently using the so-called pseudo-signature approach (I 
>> currently prefer this approach):
>> 
>> concept Clonable {
>>    clone(Clonable)->Clonable
>> };
>
> Hm.  I take it these proposals don't handle the multi-sorted case?  
> (The syntax suggests to me that these proposals aren't expressive enough
> to talk about a number of interesting concepts.)

_Please_ download and read the papers.  They're a bit sketchy, but
there's no substitute for first-hand information.

> Similarly, my hunch is that the "best" (see below) way to deal with
> Integers being twice a Monoid is similar:
>
>    class Monoid t how where
>       identity_element :: t
>       multiply :: t -> t -> t
>
>    data Integer = ...   -- whatever
>    
>    -- Some tags which mean
>    --    Integer as monoid with respect to zero and plus
>    --    Integer as monoid with respect to one and multiply
>    data IAMWRTZAP = IAMWRTZAP   -- Excuse the horrid names
>    data IAMWRTOAM = IAMWRTOAM
>    
>    instance Monoid Integer IAMWRTZAP where
>       identity_element = 0
>       multiply = (+)
>
>    instance Monoid Integer IAMWRTOAM where
>       identity_element = 1
>       multiply = (*)
>       
> This example does illustrate issues with the idea of "ownership" of
> functionality.  The way I see it, "Num" still owns the operation "+", 
> and Monoid still "owns" the operation "multiply".  Integer uses the same
> implementation code in both of these roles.  The way I've coded it
> above, "instance Num Integer" (presumably) contains the "real work" to
> add two Integers, whereas "instance Monoid Integer IAMWRTZAP" just
> "forwards" the work.  If Monoid had been defined prior to Num, it could
> have easily gone the other way, with "multiply" supplying the
> "primitive" definition, and "+" being defined in terms of "multiply".
> Both are equivalent.
>
> A couple paragraphs ago, I used the word "best".  I am not sure that
> this is actually the ideal way to represent this.  It might be better
> if there were some separate language construct which captured the
> idea/nuances of "roles".  But language design is an exercise in
> trade-offs, and in my experience, examples where one type models one
> concept in two different ways are rare in practice.  

I don't even think you have one here.  A monoid consists of a data
type, a value, and an operation.  You don't have "Integer is a
monoid".  What you've got is "(Integer,0,+) is a monoid" and
"(Integer,1,*) is a monoid".

> As a result, my hunch is that the best way to deal with cases like
> this is just to create (arguably artificial) entities as extra
> parameters to a multi-sorted concept.  

I don't think it's artificial.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com