[net.lang] Modularity in Mesa?

collberg@pandor.UUCP (Christian Collberg) (06/06/86)

Article-I.D.: pandor.120
Posted: Wed Jun 11 10:44:34 1986

Article-I.D.: pandor.120
Posted: Wed Jun  4 14:38:34 1986
Date-Received: Wed, 4-Jun-86 14:38:34+0100
Reply-To: collberg@agaton.pandor.UUCP (Christian Collberg)
Organization: Lund Institute of Technology, Sweden
Lines: 25
Keywords: Mesa, Modularity, Multiple implementations


Modularity in Mesa
------------------

   We are presently working on a project concerning modularity in strongly
typed languages. We would appreciate some information on the Mesa module
concept, especially how in Mesa there may exist several program modules
for each definition. Does the programmer himself choose the appropriate 
implementation of the module he imports or does the system make the choice?
If so, how? Any pointers to pertinent literature would be helpful. 
Unfortunately we do not have a copy of the Mesa Language Manual available.


Chris Collberg & Magnus Krampell

------------------------------------------------------------------------------

UUCP:   {mcvax, seismo} enea!agaton!pandor!collberg
Snail:  Christian Collberg
        Dept. of Comp. Sci.
        Lund University
        BOX 118
        S-221 00 LUND
        Sweden

wagner@parcvax.Xerox.COM (Michael Wagner) (06/11/86)

> Modularity in Mesa
> ------------------
> 
>    We are presently working on a project concerning modularity in strongly
> typed languages. We would appreciate some information on the Mesa module
> concept, especially how in Mesa there may exist several program modules
> for each definition. Does the programmer himself choose the appropriate 
> implementation of the module he imports or does the system make the choice?
> If so, how? Any pointers to pertinent literature would be helpful. 
> Unfortunately we do not have a copy of the Mesa Language Manual available.
> 
> 
> Chris Collberg & Magnus Krampell
> 
> ------------------------------------------------------------------------------
> 
> UUCP:   {mcvax, seismo} enea!agaton!pandor!collberg
> Snail:  Christian Collberg
>         Dept. of Comp. Sci.
>         Lund University
>         BOX 118
>         S-221 00 LUND
>         Sweden

I can think of two answers to your question. First, Mesa allows multiple
modules to collectively implement a definition, i.e., each module can implement
part of the definition. This helps to keep each modules small and they can all
be bound together to form a package which exports the entire definition.

Another slant on your question is how does Mesa allow different implementations
of the same interface. This is accomplished through C/Mesa, a small programming
language that is fed to the binder when binding modules and configurations 
together to form new configurations. (A configuration is a group of modules
and configurations bound together. The input to the binder can include both 
modules and configurations. The binder views them as the same thing.) Through 
various contortions in C/Mesa, you can choose which implemenation of a given 
interface you want to import. For instance, if BTree is an interface, BTreeImpl1
and BTreeImpl2 are different implementations of BTree, and BTreeClient1 and 
BTreeClient2 are different clients of BTree, you could say:
   bt1: BTree = BTreeImpl1[];
   bt2: BTree = BTreeImpl2[];
   BTreeClient1[bt1];
   BTreeClient2[bt2];
This would bind BTreeClient1 to BTreeImpl1 and BTreeClient2 to BTreeClient2.
Alternatively, you could say
  bt: BTree = BTreeImpl1 THEN BTreeImpl2;
  BTreeClient1[bt];
This would first bind everything that it could from BTreeImpl1 to BTreeClient1
and then get the rest from BTreeImpl2. There are many other funky things you
can do with C/Mesa, but most are rarely used. The default is to have at most
one implementation of each item in an interface and the binder will sort of
"do what I mean". You just list the implementations and the clients and the
binder figures out what you want done. Surprisingly this is sufficient for 99%
of all the cases that arise normally.