
Boost : 
From: David Abrahams (dave_at_[hidden])
Date: 20031115 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 usagepattern
>> approach (although this) is likely to change:
>>
>> concept Clonable {
>> constraints(Clonable c) {
>> clone(c);
>> };
>> };
>>
>> or equivalently using the socalled pseudosignature approach (I
>> currently prefer this approach):
>>
>> concept Clonable {
>> clone(Clonable)>Clonable
>> };
>
> Hm. I take it these proposals don't handle the multisorted 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 firsthand 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
> tradeoffs, 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 multisorted concept.
I don't think it's artificial.
 Dave Abrahams Boost Consulting www.boostconsulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk