Path: news.daimi.aau.dk!news.uni-c.dk!sunic!pipex!howland.reston.ans.net!swrinde!ihnp4.ucsd.edu!network.ucsd.edu!mbk From: mbk@inls1.ucsd.edu (Matt Kennel) Newsgroups: comp.object,comp.lang.eiffel,comp.lang.sather,comp.lang.beta,comp.lang.modula3 Subject: Re: Cows, Hogs & Farms Followup-To: comp.object,comp.lang.eiffel,comp.lang.sather,comp.lang.beta,comp.lang.modula3 Date: 7 Jan 1995 00:31:37 GMT Organization: Institute For Nonlinear Science, UCSD Lines: 99 Message-ID: <3eknd9$noi@network.ucsd.edu> References: <1995Jan6.164948.4782@schbbs.mot.com> NNTP-Posting-Host: lyapunov.ucsd.edu X-Newsreader: TIN [version 1.1 PL8] Xref: news.daimi.aau.dk comp.object:23516 comp.lang.eiffel:7122 comp.lang.sather:1393 comp.lang.beta:203 comp.lang.modula3:3304 David L. Shang (shang@corp.mot.com) wrote: : 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. 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. : 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. Right it's a limitation that the generic type parameter is nameless. : 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. 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. : 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. What is this exactly? I guess I don't quite see. Sather and Eiffel et cetera are statically typed in this sense: there is no notion of a variable which contains a "type" that can be modified at run-time, and new objects made in a fashion which depend on this run-time type as a generic parameter. I guess I don't quite understand the implications or meaning of when this is not the case. All type parameters must be resolved at compile time; there must be some performance benefit, yes? For example if you have run-time computatble types, you have to conceivably deal with all legal specializations of some generic type, for the type parameter might be some value comptuted at run-time which in general might be unknown. : David Shang -- -Matt Kennel mbk@inls1.ucsd.edu -Institute for Nonlinear Science, University of California, San Diego -*** AD: Archive for nonlinear dynamics papers & programs: FTP to -*** lyapunov.ucsd.edu, username "anonymous".