Re: Trouble understanding define (!)

[Jost Boekemeier <jostobfe at linux dot zrz dot TU-Berlin dot DE>]

>>> You have a module "draw" which exports several names:
>>> draw<int>...
>>> draw<grapics><line>...
>>> draw<grapics><point>...
>>> draw<cards><field>...
>>> draw<cards><card>...
>> The modules are "graphics" and "cards".  The name being exported is
>> "draw".
>Yes.  But what if we handle classes as modules?  A GF would be a
>module and a class with its data structure would be a module.  Et
>voila...

More precisely: The names being exported from module "draw" are <int>,
<graphics><line>, <graphics><point> ...  Of course, they are invisible
to users.  


[I wrote:]
> ML´s parametric modules are just another word for "generics": They
> dispatch on their arguments (only one in ML) and produce a concrete
> value (the concrete module in this case).

Here's what generics do (short form: M[P_1,...P_n] -> V):
           
            1        $n$
            M ---->   C   1   
             (uses)   ^
                      |
                      P  $n$ 
  

Example: 

signature SYMBOL = sig [...] end;
signature SYNTAX = sig structure Symbol: SYMBOL [...] end;

functor MakeSymbol(): SYMBOL = struct [...] end;
functor MakeSyntax(Symbol: SYMBOL): SYNTAX = 
   struct
      structure Symbol: SYMBOL = Symbol
   [...]
end;

structure Symbol: SYMBOL = MakeSymbol();
structure Syntax: SYNTAX = MakeSyntax(Symbol);

In the above example C is SYMBOL, P is Symbol and M is Syntax.

If you declare function prototyps in SYMBOL's interface, the concrete
methods in each of the Symbol implementations and let Syntax call
these functions, you have multiple dispatch.  You can think of SYMBOL
as the GF, $n$ concrete implementations (Symbol) and the container
(Syntax) which uses them.


Jost