Re: Trouble understanding define (!)

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE> writes:

> I donīt understand this part:
> 
> > The problem, as I see it, is that it is uncomfortable for the user to
> > manage the question of which GFs of the same name really should be
> > represented as one GF.
> > 
> > We might have one graphics library which provides a set of methods for
> > the GF `draw'.  Then we might use this in a Poker game where we have a
> > GF `draw' which draws cards in different ways depending on what kind
> > of pack of cards we have.
> 
> 
> You have a module "draw" which exports several names:
> draw<int>...
> draw<grapics><line>...
> draw<grapics><point>...
> draw<cards><field>...
> draw<cards><card>...
> 
> If draw<cards>... should only visible to client module "game", just do
> a selective export and youīre done.  Or do I miss something important?

The modules are "graphics" and "cards".  The name being exported is
"draw".

> I have problems with the sentence "depending on what kind of pack the
> cards have".  What does this mean?

"different ways" means different methods.
"kind of pack" means class of pack (there are different subclasses of
<cardpack>).

> > It is clear that these two GFs represent different concepts, and one
> > way of handling the situation in the module system is to import with
> > renaming: g:draw, card:draw.
> 
> In Clos generic functions donīt represent different concepts as they
> donīt belong to classes.

A generic function represents the concept of a certain action, such as
the action of "drawing a figure" and the action of "drawing a card".

> PS: An alternative for selective export would be "parametric modules", IMHO.

My impression is that parametric modules are used to re-use code, so
that one module "template" can be instantiated in many ways depending
on the parameter, for example a phone register using any of a number
of database implementations.  I don't see how this could help us here.