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".
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk