Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!houxm!mhuxt!m10ux!mnc From: mnc@m10ux.UUCP Newsgroups: comp.lang.misc Subject: Re: OOPS Message-ID: <158@m10ux.UUCP> Date: Fri, 13-Feb-87 11:44:59 EST Article-I.D.: m10ux.158 Posted: Fri Feb 13 11:44:59 1987 Date-Received: Sun, 15-Feb-87 01:16:17 EST References: <364@oracle.tc.fluke.COM> <814@unc.unc.UUCP> <1040@tekchips.TEK.COM> Distribution: comp.lang.misc Organization: AT&T Bell Labs, Murray Hill, NJ Lines: 57 In this discussion, there have been some misunderstandings and arguments caused by the failure to give clear definitions of such terms as "dynamic binding". In order to promote a higher level of discourse, I herewith offer the following definitions, which are fairly clear and precise. I trust that they also agree with the widely accepted meanings: "dynamic vs. static binding" -- (unfortunately vague terms, since it is not clear WHAT is being bound -- a better term for static binding is "static scope" or "lexical scope".) A language is staticly bound iff for any two references to a variable named x in any program, it is computable whether the two references refer to the same object (i.e. the same location in memory). Otherwise it is dynamically bound. Note: This implies that programs in statically bound languages cannot compute variable names at run time -- names must appear literally in the text at the point of reference. Conversely, dynamically bound languages must employ some sort of symbol table at runtime, unlike statically bound langugages, even if they do not allow the construction of variable names at run time. Also, note that by "variable", above, I mean an identifier, not Pascal's notion of variable, which would include x[i], x^ and x.a. Thus in a statically bound language, you are not necessarily able to tell at compile time whether two occurrences of x[i] refer to the same object. Similarly, having pointers to functions does not make a language dynamically bound, either. "dynamic vs. static typing" -- A language is statically typed iff for any reference to a variable x in any program, the type of x is computable. Note: this makes the definition depend rather strongly on how you define the word "type" for any particular language. For example, LISP can be seen as a statically typed language in which every variable has the same type. This type is a structure containing a type tag field and a variant part (union) containing either a pair of pointers, called CAR and CDR, to other such structures, or a character string, integer, etc. This seems like cheating to me, but I don't think you can formulate a definition that prohibits this interpretation. A more reasonable definition might result if we said that you only know the type of a variable x if, given just the address of x (and without looking at the value of x) you know how to copy x to y, what the valid sub-pieces of x are, and whether it is well-defined to apply any given function f, whose type is known, to x. This, however, would seem to say that C variables of union types are dynamically typed (and perhaps they are). Using the above definitions, it is clear that a language cannot be dynamically bound and staticly typed, unless you make the bizarre requirement a la FORTRAN that every variable named x must have the same type, even if they are otherwise completely unrelated. Otherwise, it is not computable whether a reference to variable x is referring to the x that was defined as an integer or the x that was defined somewhere else as a character string. It is also clear that a language CAN be statically bound and dynamically typed (e.g. SCHEME, or any other statically bound version of LISP). Does this help clear things up a bit? -- Michael Condict {ihnp4|vax135}!m10ux!mnc AT&T Bell Labs (201)582-5911 MH 3B-416 Murray Hill, NJ