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.