Boost logo

Boost :

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
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at