Boost logo

Boost :

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-11-17 11:48:28

On Sat, Nov 15, 2003 at 05:25:17PM -1000, David Abrahams wrote:
> Brian McNamara <lorgon_at_[hidden]> writes:
> > 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.

You may be right. This example is a little confounded by the fact that
whereas "Integer" is a type, "0,+" or "1,*" are values. Types, not
values, model concepts, which is why I had to invent the (tag) types
which corresponded to "ZeroAndPlus" or "OneAndMultiplies".

But anyway.


I was recently reminded of "subject-oriented programming", where a
single object can present different interfaces to different "subjects"
(viewers) of the object. The intersection (product) of object and
subject is called a "role". The typical example: a tree (the green
leafy kind, not the data structure) is seen as a "home" by a bird, or as
a "material source" by a lumberjack. We end up with

   class BirdHouse h where
      liveInIt :: Bird -> h -> ()

   class Material m where
      buildABridgeOutOfIt :: m -> Bridge

   data Tree = ...

   instance Home Tree where ...
   instance Material Tree where ...

I mainly bring it up to mention "subject-oriented programming" as a
keyword for anyone who might want to explore more in this direction.

-Brian McNamara (lorgon_at_[hidden])

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