Re: [boost] Re: compile time member detection

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.

Only-somewhat-relatedly:

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