Xref: utzoo comp.lang.misc:7164 comp.object:2962 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!bionet!parc!boehm From: boehm@parc.xerox.com (Hans Boehm) Newsgroups: comp.lang.misc,comp.object Subject: Re: CHALLENGE: typing and reusability Message-ID: Date: 29 Mar 91 19:18:45 GMT References: <22032@yunexus.YorkU.CA> <11820:Mar1923:59:3591@kramden.acf.nyu.edu> <19MAR91.22493670@uc780.umd.edu> <18271:Mar2013:19:1091@kramden.acf.nyu.edu> <1991Mar20.214231.3411@neon.Stanford.EDU> <1121@tetrauk.UUCP> Sender: news@parc.xerox.com Organization: Xerox PARC Lines: 48 rick@tetrauk.UUCP (Rick Jones) writes: >This proposition is actually the crux. It maintains that two completely >unrelated types, which _happen_ to have two features/methods of corresponding >names (and we will assume signatures :-), can be used interchangeably by client >code which is only interested in those features. But there is a difference >between _looking_ the same and _being_ the same. >Both a letter and an invoice may support an operation "post", but it doesn't >mean that you are doing the same thing to both of them. The letter you post to >the mail, the invoice to the ledger. It's even more subtle if you also >consider an invoice to be a sub-type of letter which can also be posted to the >mail. Names in themselves are not as significant as they suggest. Eiffel has >demonstrated this in its handling of multiple inheritance, where it allows >features to be renamed on inheritance (the _same_ feature can have a >_different_ name in the context of a sub-class; how do you handle that with >dynamic typing?). Names are really a syntactic convenience. Granted, using names in this context is far from perfect. Using names and types together is a little closer, but still not perfect. But I often don't care that the two operations are in any sense the same, only that they share certain properties. For example, I might define a routine that raises a value to an integer power by repeated squaring. It should care only that I have an associative multiplication operation available, and perhaps a multiplicative identity. I should be able to invoke this operation on the string "a" and the integer 200, with concatenation acting as multiplication, in order to get a string of 200 "a"s. (In a language that doesn't allow destructive updates of strings, this may even be the most efficient way to accomplish this task.) But this doesn't mean that concatenation and integer multiplication are in any sense "the same". It also points out (as RickJones stated) that defining "the same" using inheritance is way off. Arguing that strings and integers should inherit from a class of "monoids" seems to me to be really pushing it, and requires way too much foresight by the class hierarachy designer. (Furthermore integer could inherit in two different ways from such a class. A priori, I don't know whether plus or times is the interesting operation.) I think IBMs Scratchpad II comes closest to getting this issue right, in that (as I recall) the language allows operations in algebras to be annotated with properties such as "associative". Their existence is checked in cases like the above. There is of course no way for the compiler to associate any semantics with the word "associative"; it's treated simply as an uninterpreted property that some operations are asserted to have. Hans-J. Boehm (boehm@xerox.com) Usual disclaimers ...