budd@orstcs.cs.ORST.EDU (06/29/87)
I may be showing my vast ignorance again, but somehow I just don't see how adding type declarations to Smalltalk helps anything. It would seem as if one of the following cases must apply 1. The C philosophy - the user can give declarations, but these are not checked at run time. You pass something that doesn't match the declaration, your program will crash and burn. Not very nice. 2. The Pascal philososphy - declarations are all checked statically at some point long before run time. Either requires declarations everywhere (too restrictive and limits polymorphism) or requires extensive data flow analysis (complicated). 3. Hidden code is created to check the conformability of argument types with declarations prior to method execution. Why is this any more efficient than user written code to do the same task? Allowing the user to do it would seem to be more flexible. And what happes when the declarations are violated? Does the user have any recourse? 4. Types are considered as part of the message pattern for the purposes of method lookup. (This is an extension of object message lookup, where the types of arguments other than the first may also be important). This would seem to be the most general solution, since the only overhead involved is that of method lookup, not argument checking, and tricks such as caching can be used to speed up message lookup. Never the less, the Smalltalk notion of class is not the most useful concept of type that could be envisioned, and again this limits polymorphism. In short, there seems to be an implicit conflict between strong typing, or typing of any sort, and polymorphism. Strengthing one limits the other. Smalltalk has come down strongly on the side of polymorphism, and even I (Smalltalk heretic than I am) have a hard time imagining anything similar to Smalltalk that changes this. I am looking forward to hearing how I am all wrong, and how option number 5 makes all problems go away. --tim budd (budd@oregon-state)
kempf@hplabsc.UUCP (Jim Kempf) (07/01/87)
An alternative to explicit typing is type inference (inferring the type from the code). Languages such as ML, which were designed with type inference in mind, do this very well. The proceedings of POPL-8 include a paper by Norihisa Suzuki on how to do this in Smalltalk. Jim Kempf kempf@hplabs.hp.com
delano@calma.UUCP (Pat Delano) (07/01/87)
> > In short, there seems to be an implicit conflict between strong typing, or > typing of any sort, and polymorphism. Strengthing one limits the other. > Smalltalk has come down strongly on > the side of polymorphism, and even I (Smalltalk heretic than I am) have a > hard time imagining anything similar to Smalltalk that changes this. > > I am looking forward to hearing how I am all wrong, and how option number 5 > makes all problems go away. > > --tim budd (budd@oregon-state) I highly recommend an article I just finished: "On Understanding Types, Data Abstraction, and Polymorphism" by Cardelli and Wegner in ACM Computing Surveys, December 85. I'm not saying that you are wrong, but I think you may find the article very interesting. I thought it was excellent on first reading, and I plan to read it again. Here are a couple of quotes from the article: "Our objective is to understand the notion of type in programming languages, present a model of typed, polymorphic languages that reflects recent research in type theory, and examine the relevance of recent research to the design of practical programming languages. Object-oriented languages provide both a framework and a motivation for exploring the interaction among the concepts of type, data abstraction, and polymorphism, since they extend the notion of type to data abstraction and since type inheritance is an important form of polymorphism." Toward the end of the article: "Smalltalk and LISP Flavors have some idioms that cannot be reproduced because they are essentially impossible to type check statically. ... Generally, the freedom of type-free languages is hard to match, but we have shown in previous sections that polymorphism can go a long way toward achieving flexibility, and bounded quantification can extend that flexibility to inheritance situations." -- --- Patrick DeLano {sun,ucbvax}!calma!delano GE Calma Company 525 Sycamore Drive Milpitas, CA 95035 telephone 408 434-4429 ---
kens@hpldola.HP.COM (Ken Shrum) (07/01/87)
>In short, there seems to be an implicit conflict between strong typing, or >typing of any sort, and polymorphism. Strengthing one limits the other. >Smalltalk has come down strongly on >the side of polymorphism, and even I (Smalltalk heretic than I am) have a >hard time imagining anything similar to Smalltalk that changes this. > >I am looking forward to hearing how I am all wrong, and how option number 5 >makes all problems go away. >--tim budd (budd@oregon-state) Smalltalk combines protocol definitions and method implementations into a class. Let us consider having a class Protocol whose instances represent protocols. Presumably the instances support operations to join/intersect a set of protocols, etc. Each class may have an instance of Protocol associated with it, describing the protocol presented by instances at runtime. 5. Type declarations state that 'the protocol of this object is a superset of this protocol'. This information could be used only for type checking or it could also be used at runtime. This solution only solves the syntax problem, but supports polymorphism as it is presently supported by Smalltalk. Ken Shrum hplabs!hpldola!kens
bmc@argus.UUCP (Bob Czech) (07/03/87)
In article <245100009@orstcs>, budd@orstcs.cs.ORST.EDU writes: > > 4. Types are considered as part of the message pattern for the purposes of > method lookup. (This is an extension of object message lookup, where the > types of arguments other than the first may also be important). This would > seem to be the most general solution, since the only overhead involved is > that of method lookup, not argument checking, and tricks such as caching > can be used to speed up message lookup. Never the less, the Smalltalk > notion of class is not the most useful concept of type that could be > envisioned, and again this limits polymorphism. > I see it as a way of cutting out the run time overhead of a message lookup with typing of variables. In this way the exact method is bound to the variable during compile time. There is no need for a message lookup at runtime because you have the class of the recevier already specified. Are there any versions of smalltalk around that use early binding?
anders@suadb.UUCP (Anders Bj|rnerstedt) (07/04/87)
In article <orstcs.245100009> budd@orstcs.cs.ORST.EDU writes: > >2. The Pascal philososphy - declarations are all checked statically at some >point long before run time. Either requires declarations everywhere (too >restrictive and limits polymorphism) or requires extensive data flow >analysis (complicated). Declarations (which may be checked statically) certainly limit polymorphism, that is the whole point of typing. However declarations do not exclude polymorphism, as long as the actual (run-time) value is of a type satisfying the formal declaration, e.g. the value is of the same type or a subtype of the declaration, then the expression is type correct. >3. Hidden code is created to check the conformability of argument types >with declarations prior to method execution. Why is this any more >efficient than user written code to do the same task? Allowing the user to >do it would seem to be more flexible. And what happes when the >declarations are violated? Does the user have any recourse? Why use high level languages at all ? Compiler generated run-time checks are less errorprone, code easier to maintain. >In short, there seems to be an implicit conflict between strong typing, or >typing of any sort, and polymorphism. Strengthing one limits the other. I agree that there is a trade-of involved. Typing can be seen as the limitation of polymorphism (though not the elimination of polymorphism). This is at the expense of flexibility but for the benefit of security. Depending on the size of a software project or the number of individual programmers involved this will be more or less important. --------------------- Anders Bjornerstedt Department of Information Processing & Computer Science University of Stockholm S-106 91 Stockholm Sweden UUCP:{seismo,mcvax,cernvax,diku,ircam,prlb2,tut,ukc}!enea!suadb!anders ARPA: enea!suadb!anders@seismo.arpa
anders@suadb.UUCP (Anders Bj|rnerstedt) (07/06/87)
In article <argus.943> bmc@argus.UUCP (Bob Czech) writes: > > In article <245100009@orstcs>, budd@orstcs.cs.ORST.EDU writes: > > > > 4. Types are considered as part of the message pattern for the purposes of > > method lookup. (This is an extension of object message lookup, where the > > types of arguments other than the first may also be important). This would > > seem to be the most general solution, since the only overhead involved is > > that of method lookup, not argument checking, and tricks such as caching > > can be used to speed up message lookup. Never the less, the Smalltalk > > notion of class is not the most useful concept of type that could be > > envisioned, and again this limits polymorphism. > > > > I see it as a way of cutting out the run time overhead of a message >lookup with typing of variables. In this way the exact method is bound to the >variable during compile time. There is no need for a message lookup at runtime >because you have the class of the recevier already specified. Typing may be used by the compiler to make early binding (binding to the concrete type you might say) in order to gain efficiency. However you then exclude polymorphism. You may still want typing AND late binding (binding to the abstract type you might say) in order to have both flexibility (polymorphism) and security, i.e. the object is guaranteed to support a certain protocol. --------------------- Anders Bjornerstedt Department of Information Processing & Computer Science University of Stockholm S-106 91 Stockholm Sweden UUCP:{seismo,mcvax,cernvax,diku,ircam,prlb2,tut,ukc}!enea!suadb!anders ARPA: enea!suadb!anders@seismo.arpa
johna@cognos.uucp (John C. Anderson) (07/06/87)
In article <245100009@orstcs> budd@orstcs.cs.ORST.EDU writes: > [... deleted ...] >In short, there seems to be an implicit conflict between strong typing, or >typing of any sort, and polymorphism. Strengthing one limits the other. >Smalltalk has come down strongly on >the side of polymorphism, and even I (Smalltalk heretic than I am) have a >hard time imagining anything similar to Smalltalk that changes this. > >I am looking forward to hearing how I am all wrong, and how option number 5 >makes all problems go away. > Well, I dont think there is an option 5 which will "make all problems go away", however, there is an option 4.78 which goes a long way in the right direction. A detailed reply would be too lengthy for inclusion here, but I'll give a brief indication of the flavour of the solution, and some pointers to the literature which you can chase down if you're interested. To start with, I have to (mildly) disagree with your statement that polymophism and strong typing are in conflict. It is true that strong typing as exhibited by, eg Pascal, is in conflict with polymorphism. However, the real problem here is not strong typing, but that the type theory used in Pascal is extremely primitive. For example, to describe the (polymorphic) concept "pair of t" where t is any type is quite impossible in Pascal. You can describe "pair of int", or "pair of real", etc (as a record or two element array), but you can never describe the general concept. However, there are languages in existence today which have a much more powerful notion of type. These languages are quite capable of mixing strong typing with polymorphsim and generally can handle concepts like "pair of t" quite easily and efficiently. One such language which is quite well known is ML. See "A Proposal for Standard ML" by R. Milner, in the Proceedings of the Symposium on LISP and Functional Programming Aug/84. There is an excellent article in Computing Surveys, December 1985, "On Understanding Types, Data Abstraction, and Polymorphism", by Cardelli and Wegner. This article covers the key issues, and is quite readable. If nothing else, I suggest this article. C & W demonstrate the combination of polymorphism and strong typing, and in addition show how the inheritance mechanism of Smalltalk provides for certain restricted forms of polymorphism. > [ ... repeated from above ] >I have a hard time imagining anything similar to Smalltalk that changes this. Please have a look at "An Exemplar Based Smalltalk", Lalonde, Thomas, and Pugh, in the Proceedings of OOPSLA'86 (Object-Oriented Programming Systems, Languages and Applications). -- John Anderson, Cognos Incorporated, 3755 Riverside Drive, Ottawa, Ontario, CANADA K1G 3N3 (613) 738-1440 decvax!utzoo!dciem!nrcaer!cognos!johna
johnson@uiucdcsp.UUCP (07/06/87)
Suzuki's type inference system works only with a subset of Smalltalk. In particular, it does not work with parameterized classes such as Collections. Cardelli and Wegner's paper is must reading for anybody doing research in type systems or in object-oriented programming. Unfortunately, it is not as applicable to Smalltalk as one might think, since ad-hoc polymorphism is important in Smalltalk, in my opinion more important than inclusion polymorphism. (Actually, I might have gotten that last kind of polymorphism wrong---it's the kind that Cardelli and Wegner spend most of their time on.) However, I learned a lot from reading their paper and it has greatly influenced my work.
daniels@cae780.TEK.COM (Scott Daniels) (07/06/87)
In article <245100009@orstcs> budd@orstcs.cs.ORST.EDU writes: >I may be showing my vast ignorance again, but somehow I just don't see how >adding type declarations to Smalltalk helps anything. It would seem as if >one of the following cases must apply > >1. C - user gives declarations, not checked at run time. >2. Pascal - declarations checked statically >3. Hidden code checks conformability of argument types with declarations > Why is this any more efficient than user written code to do the same task? >4. Types are part of the message pattern (Generics) > >option number 5? In response to your comment on (3): How about the value this provides to the reader of the code? Given the language guaranteed a certain type was provided, the code might read much more easily. This would mean treating the declaration as a kind of "ASSERT". As for a (5), how about: The type provides advice to the compiler to build code which works more efficiently if the given class of object is provided. A simple check and branched code, with slow compact code for the abnormal case, and fast code for the provided declaration. Thus this might be analogous to the "register" declaration in C (and you might also give compile- time warnings if messages that the declared class was unable to handle were sent to the objects so declared). FROM: Scott Daniels, Tektronix CAE 5302 Betsy Ross Drive, Santa Clara, CA 95054 UUCP: tektronix!teklds!cae780!daniels {ihnp4, decvax!decwrl}!amdcad!cae780!daniels {nsc, hplabs, resonex, qubix, leadsv}!cae780!daniels