Newsgroups: comp.object,comp.lang.eiffel,comp.lang.sather,comp.lang.beta,comp.lang.modula3
Path: news.daimi.aau.dk!news.uni-c.dk!sunic!uunet!ftpbox!mothost!schbbs!news
From: shang@corp.mot.com (David L. Shang)
Subject: Re: Cows, Hogs & Farms
Reply-To: shang@corp.mot.com
Organization: MOTOROLA 
Date: Mon, 9 Jan 1995 18:36:27 GMT
Message-ID: <1995Jan9.183627.26161@schbbs.mot.com>
References: <3eknd9$noi@network.ucsd.edu>
Sender: news@schbbs.mot.com (SCHBBS News Account)
Nntp-Posting-Host: 129.188.128.126
Lines: 115
Xref: news.daimi.aau.dk comp.object:23586 comp.lang.eiffel:7134 comp.lang.sather:1402 comp.lang.beta:208 comp.lang.modula3:3312

In article <3eknd9$noi@network.ucsd.edu> mbk@inls1.ucsd.edu (Matt Kennel)  
writes:
> Ok you could do this in Sather by just saying
> 
> illinois: MONOCULTUREFARM{GRASS,$HERBIVORE{GRASS}}
> 
> and so the animals in 'illinois' would be anything that could eat grass.

This is my Cluster's version in (2), which I used to describe an euivalent form  
to the Sather's orignal version. Now you translate it back into Sather.

To use MONOCULTUREFARM in version (2),  Cluster has the equivalent form:

illinois: MONOCULTUREFARM[GRASS,HERBIVORE[GRASS]]

where illinois could be a farm with cows, sheeps, and any other creatures that  
are subclasses of HERBIVORE[GRASS], or,

illinois: MONOCULTUREFARM[GRASS,COW]

where illinois is a cow farm if we suppose that COW be a subclass of  
HERBIVORE[GRASS].

In Cluster's version (1), you can simply written:

illinois: MONOCULTUREFARM[HERBIVORE[GRASS]], or
illinois: MONOCULTUREFARM[COW]

In Cluster's version (3), you can simply written:

illinois: MONOCULTUREFARM[GRASS]

> : ... by Cluster, HERBIVORE[GRASS] is a subclass/subtype  
> : of HERBIVORE. By Sather, HERBIVORE[GRASS] cannot be a subclass/subtype of  
> : HERBIVORE. That's whay Sather cannot have the expression:
> 
> : 	ANIMALT < $HERBIVORE
> 
> : because HERBIVORE is not a class.
> 
> OK.  But you could write a type $HERBIVORE > $HERBIVORE{FOODT} that
> specified just those features not dependent on FOODT (say
> "eat_or_barf(x:$PLANT)"), and so all COW's and HOG's could be a subclass of
> some $HERBIVORE, if somewhere else you needed to classify ANIMAL's on the
> basis on whether or not they were an $HEBIVORE.
> 

Is it a little bit strange to have a hieratchy like:

	$HERBIVORE > $HERBIVORE{FOODT} > COW

? Is HERBIVORE{FOODT} or HERBIVORE{GRASS} a real class by Sather? If they are  
not, what is the relationship between:

	HERBIVORE > HERBIVORE{FOODT}

and

	HERBIVORE{FOODT} > COW

? The only valid relationship I see is:

	HERBIVORE > COW

HERBIVORE dose not have any information on the food type. If we try to classify  
herbivores accroding to their food types, this HERBIVORE class could not help  
more than what we have like this:

	ANY_OBJECT > COW

> 
> All type parameters must be resolved at compile time;
> there must be some performance benefit, yes?

Not necessarily true. Class paprameters can be resovled at run time by Cluster.  
This is done by dynamic binding. I don't see any significant performance  
slowing down by just an indirect access when a dynamic binding must be  
performed. The benefit is the power of dynamic typing. For example:

	farm: MONOCULTUREFARM; // a polymorphic farm variable;
	creature: HERBIVORE; // a polymorphic herbivore animal varaible;
	...

	creature := aMixedmarket.GetHerbivoreFromMixedMarket();
		// at this point, we do not know the exact type of
		// the creature.
	...
	farm := new MONOCULTUREFARM[typeof(creature)];
		// create a farm in a new class accroding to
		// the type of the creature
	when typeof(farm).ANIMALT is typeof(creature) do
		farm.add(creature);

The last type assurance statement is used for type-safety, because 

	creature -> farm.add's input

is a cross assignment, which, like a reverse assignment, violates the  
substitution law. The compiler won't let the program pass if the type assurance  
statement is not used.

However, the type assurance statement may not necessary accroding to the  
context. It could be eliminated by optimization. It is the same case as:

	var i: integer := 4;
	if i=4 then i++;

Therefore, all the programs passed by the compiler will be type safe. No system  
level type check or data flow analysis is required for type safety. They are  
required only for the purpose of code optimization.


David Shang