Xref: utzoo comp.lang.objective-c:234 comp.lang.misc:7485 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!uunet!bywater!arnor!andreadoria!strom From: strom@watson.ibm.com (Rob Strom) Newsgroups: comp.lang.objective-c,comp.lang.misc Subject: Re: Optional static typing limits Keywords: static typing, dynamic typing, Hermes Message-ID: <1991Apr17.164655.13906@watson.ibm.com> Date: 17 Apr 91 16:46:55 GMT References: Sender: news@watson.ibm.com (NNTP News Poster) Reply-To: strom@andreadoria.watson.ibm.com (Rob Strom) Followup-To: comp.lang.misc Organization: IBM T.J. Watson Research Center Lines: 101 Nntp-Posting-Host: andreadoria In article , liberte@ncsa.uiuc.edu (Daniel LaLiberte) writes: |> I wonder if we can raise the level of the dicussion |> on static vs dynamic types to consider more generally where |> static typing fails to be sufficient or convenient, and why. |> |> I am also interested in the various ways languages that support |> *optional* static typing limit the extent of static typing one can do, |> and why. First of all which languages support optional static typing? I'll answer this question for the Hermes language. Hermes provides both strong static typing and strong dynamic typing. That is, it is never possible to apply an operation to an operand of an inappropriate type. This guarantee is sometimes enforced by compile-time checking (static), and sometimes by run-time checking (dynamic). Which technique is used is the programmer's choice --- in this sense static typing is "optional". However, I will candidly admit that Hermes is biased towards the static approach. That is, the language design assumes that most of the time, a variable will: (1) hold values of only a single type, and (2) that type will be known at compile-time. The cases in which the type is not known statically are assumed to occur less frequently. The constructs for manipulating dynamically typed data are more verbose. This bias comes partially from the historical tradition of the language, and partially from the intended application domain: large, long-lived, multi-application systems, in which ease of maintenance is more important than ease of initial writing. In that domain, type declarations serve as a form of machine-readable documentation. |> |> I would guess that static typing is made optional in some languages |> because the designers recognized that static typing does not handle |> all typing situations, and thus dynamic typing (or, alternatively, |> C-like void typing) is a useful analog of the goto statement. |> But given optional static typing, the language designers could then |> get lazy and not provide sufficient static typing capability for even |> well known situations. |> |> [examples from Objective-C and C++] |> |> What are some other categories of problems that don't fit in existing |> static typing systems? Is it possible to come up with a "fix" for |> these problems in the ideal language, or will dynamic typing always be |> "necessary", like goto is. Can we organize these and maybe learn |> something about the problem? |> I agree that there will always be problems for which static typing will be inadequate and therefore that an escape into dynamic typing will be necessary. I don't see the need for "language wars" between proponents of static vs. dynamic typing. When static typing is possible, I prefer it, because I always prefer errors to be caught before a program module begins executing rather than in the middle of execution. When static typing is impossible, I prefer dynamic typing over escaping from type-checking altogether. Had Hermes a different application domain, we might have chosen to make dynamic typing the default and static the exception, rather than the other way around. Here are some applications for which Hermes uses dynamic typing rather than static: o On-the-fly program creation: Hermes has a data type "program" whose value is a syntax-free representation of a Hermes program. Program values can be built at run-time and then instantiated as processes with a particular initialization interface. It is checked at instantiation time that the program you have built is type consistent with the initialization interface you expect. o Name servers: In Hermes, the right to access a service is encoded as a value of a particular "output port" type. A name server is a process which, in its simplest form, owns a table of pairs . This table is typically heterogeneous since the "port" components will be of different types, representing the different services being named. o File systems: This is a situation similar to name servers. A file system is a table of pairs , but the s are of different types. Here is a situation in which Hermes can use static typing where some other languages cannot: Suppose I am managing a collection of operator consoles. These operator consoles have heterogeneous protocols: some are ASCII glass teletypes, some are bitmap displays, some are "windows", etc. However, all support a standard *interface* for printing and reading lines, prompting, etc. In Hermes these console "objects" (called "processes" in Hermes) are visible only through their ports. Since the ports have the same interface, they appear to the console manager as a homogeneous collection. The fact that these console objects have different internals does *not* make them different types. In some other languages, they *would* look heterogeneous. For example, they would be different task types in Ada, and different classes in Smalltalk. Hermes would not need dynamic typing to handle a case like this. Your Objective-C problem has no analog in Hermes. Please note that followups are directed to comp.lang.misc. -- Rob Strom, strom@ibm.com, (914) 784-7641 IBM Research, 30 Saw Mill River Road, P.O. Box 704, Yorktown Heights, NY 10958