Path: news.daimi.aau.dk!olm
From: olm@daimi.aau.dk (Ole Lehrmann Madsen)
Newsgroups: comp.object,comp.lang.beta
Subject: Re: OO languages that don't support multiple inheritence
Date: 11 Nov 1996 19:42:25 GMT
Organization: DAIMI, Computer Science Dept. at Aarhus University
Lines: 140
Message-ID: <567vj1$npm$1@gjallar.daimi.aau.dk>
References: <3267E3F7.161E@objectime.com> <54jkqn$df9@cygnus.mincom.oz.au> <tdunnava.584.001CCB51@Neosoft.Com> <yf3k9ryoeje.fsf@sabi.demon.co.uk> <56772d$d2p@whitbeck.ncl.ac.uk>
NNTP-Posting-Host: clematis.daimi.aau.dk
X-Newsreader: NN version 6.5.1 (NOV)
Xref: news.daimi.aau.dk comp.object:63643 comp.lang.beta:10875

In <56772d$d2p@whitbeck.ncl.ac.uk> "R. Kerr" <R.Kerr@ncl.ac.uk> writes:
> ....
>It may be worth mentioning that for SIMULA multiple inheritance
>poses problems over and above the normal dilemmas.  SIMULA objects
>may be active and possess split bodies (the "inner" concept).  It is
>not clear how the active body of a subclass should be combined with
>those of its parents in the multiple inheritance situation.

Multiple inheritance has been discussed for many years for BETA, which
in many ways is influenced by SIMULA, but MI has not been included in
BETA. (A further discussion of this may be found in the BETA language FAQ).

But since Ron has mentioned the issue of "inner" and MI, some people
might perhaps be interested in a possible solution discussed for BETA.

Consider class patterns:

	A: (# ... do ImpA1; INNER; ImpA2 #);
        B: (# ... do ImpB1; INNER; ImpB2 #);

And consider a class pattern "C" subclassing from "A" and "B";

	C: A & B (# ... do ImpC #)

The semantics of executing an instance "C" is then defined to be:

	"ImpA1" and "ImpB1" are executed in unspecified some order, 
		i.e. either "ImpA1; ImpB1" or "ImpB1; ImpA1".
	Then "ImpC" is executed,
	and finally "ImpA2" and "ImpB2" are executed in unspecified some order, 
		i.e. either "ImpA2; ImpB2" or "ImpB2; ImpA2".

The motivation for this semantics includes

1.	A superclass sets up an implicit assertion to be true
	before its inner is executed. This means that the code
	before inner in A and B should have been executed before executing
	the do-part of C.

2.	Similarly the do-part of an object should be executed before
	the code after inner in its superclasses.

3.	In general the order of the superclasses should not matter.
	Therefore the non-determinism in the semantics.

In the above example '&' is used to express MI, and the semantics in combining
do-parts involves nondeterminism.

One could imagine several MI operators

	*	C: A ; B (# .... #)

		could mean that there is an ordering on the do-parts
		(CLOS style)

	*	C: A || B (# ... #)

		could mean that the do-parts of of A and B before and after
		INNER are executed concurrently


The following is an example of how MI on control patterns could be used.
Consider control structures

	forTo: (# low, high, inx: @integer
	       enter(low,high)
	       do low -> inx;
		   L: (if inx <= high then 
			INNER ;
		        inx + 1 -> inx;
			restart L
		      if)
	       #);

	while: (# cond:< booleanValue
	       do R: (if cond then
			 INNER;
			 restart R
		      if)
	       #)

The above control structures are similar to the ones in the BETA basic
libraries. They may be used as follows:

	(10,100) -> forTo(# do  inx -> doIt #)

will execute inx -> doIt for inx in [10,100], where doIt is some arbitrary 
procedure pattern.

	while(# cond:: (# do BoolExp -> value #)
	     do ImpW
	     #)

will execute ImpW as long as the boolean expression BoolExp is true.

Using MI the 2 control patterns may be combined into

	(10,100) -> forTo & while (# cond:: (#do BoolExp -> value #)
				  do Inx -> doIt
			          #)

Here  inx -> doIt will be executed for inx in [10,100] but only as long
as BoolExp is true. It thus corresponds to the Algol 60 for-loop

	for i:=10 step 1 until 100 while BoolExp do ImpW;

If someone still remember Algol 60 (the syntax may be wrong!)

Now this perhaps got a bit too long. Thanks for reading so far.
Please note that MI is not part of the current BETA and that the above
constructs were suggestions. 

---olm

PS. Kristine S. Thomsen did a PhD where she generalized the above ideas
    even further.


*************** BETA information Sources ***********************************
WWW:		http://www.mjolner.dk
		http://www.daimi.aau.dk/~beta/info
News:		comp.lang.beta
FAQ:		http://www.daimi.aau.dk/~beta/FAQ
E-mail:		info@mjolner.dk
Address:	Mjolner Informatics, Science Park Aarhus,
		Gustav Wieds Vej 10, DK-8000, Aarhus C, DENMARK
Tel.:		+45 86 20 20 00
Fax.:		+45 86 20 12 22
*****************************************************************************



>Cheers....Ron

>------------------------------------------------------------------------
>  Ron Kerr, Computing Service, Newcastle University, NE1 7RU, England.
> Tel. +44 191 222 8187       Fax. +44 191 222 8765  (NOTE new area code)
>------------------------------------------------------------------------