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!mdisea!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: Fri, 6 Jan 1995 16:49:48 GMT Message-ID: <1995Jan6.164948.4782@schbbs.mot.com> References: <3eih36$94g@network.ucsd.edu> Sender: news@schbbs.mot.com (SCHBBS News Account) Nntp-Posting-Host: 129.188.128.126 Lines: 107 Xref: news.daimi.aau.dk comp.object:23493 comp.lang.eiffel:7118 comp.lang.sather:1389 comp.lang.beta:202 comp.lang.modula3:3297 In article <3eih36$94g@network.ucsd.edu> mbk@inls1.ucsd.edu (Matt Kennel) writes: > > You can do most of Cluster's static solution in Sather, and I guess Eiffel. > > ... > class MONOCULTUREFARM{FOODT, ANIMALT < $HERBIVORE{FOODT} } is > attr livestock : LIST{ANIMALT}; -- type is known at compile time > attr foodstock : LIST{FOODT}; -- type is known > ... My guess is that Eiffel can have a similar expression in its contrained generic class. How about Modula-3 and Ada9x's generic class? This form is slightly different in semantics from the Cluster's form: class MONOCULTUREFARM [ANIMALT <: HERBIVORE] attr livestock : list[ANIMALT]; attr foodstock : list[ANIMALT.FOODT]; ----- (1) or BETA's form: MONOCULTUREFARM (# ANIMALT :< HERBIVORE attr livestock : @list (# eleT::ANIMALT #); attr foodstock : @list (# eleT::ANIMALT.FOODT #); #) However, Cluster can provide the equivalent form to your Sather's vertion. There is a major difference between Cluster/BETA's generic class and Sather's. I'll discuss the major difference later. We first discuss the minor difference you mentioned: > In Cluster I guess, you could have written MONOCULTUREFARM with > just one type parameter (the ANIMAL) and then extract its preferred > food from that. You can't do that in Sather I don't think but > there isn't so much harm, as it's a compile time error to instantiate it > with a bad combination of herbivore and food. > Sometimes we should use two type parameters (in Cluster): class MONOCULTUREFARM [FOODT <: FOOD; ANIMALT <: HERBIVORE[FOODT]] attr livestock : list[ANIMALT]; attr foodstock : list[FOODT]; ----- (2) or sometimes we should use: class MONOCULTUREFARM [FOODT <: FOOD] attr livestock : list[<:ANIMAL[FOODT]]; attr foodstock : list[FOODT]; ----- (3) Semantics of (1), (2) and (3) are different. The first one means a farm with a set of animals of the same type, where a foodstock is provided to hold the food that those animals can eat. The second one mean a farm with a set of animals that eat the same food, and a foodstock is provided to hold the food. Those animals are not necessararily in the same type. Thus you can have a farm with mixed cows and sheeps. The third one mean farm with a foodstock, where a number of animals that eat its food are raised. It is basically the same as the second one: those animals are not necessararily in the same type. Thus you can put mixed cows and sheeps into the farm. The first one lay its stress on animals: farms are classified by animals. The food type is a dependent type to the animal type that the farm has. The last two lay their stress on food: farms are classified by food types. The animal type is a dependent type to the food type that the farm has. It might be difficult to argue which way is better for a farm, but as I said, the language should at least give the way that the speaker wants. Back to the major differece: Cluster's generic class are real classes but Sather's is not. Therefore, 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. What raised by the original post is really a covariance issue. Without the subclass relationship, it is meaningless to discuss the covariant relationship between COW/HOG and HERBIVORE in a type theory. Another drawback of Sather's generic class is that it cannot support a dynamic polymorphism or runtime binding based on class paramenters. Therefore, it is impposible to use Sather to specify a HETERCULTUREFARM composed of a number of MONOCULTUREFARMs -- a farm I called well-structured heterogeneous farm in my previous post. Runtime type check should be unnecessary for self-farming in this heterogeneous farm. David Shang