Article View: comp.lang.misc
Article #4655Re: OOPS
From: mnc
Date: Fri, 13 Feb 1987 16:44
Date: Fri, 13 Feb 1987 16:44
57 lines
4005 bytes
4005 bytes
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
Technical Details
Message-ID:
<158@m10ux.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!houxm!mhuxt!m10ux!mncReferences:
<364@oracle.tc.fluke.COM> <814@unc.unc.UUCP> <1040@tekchips.TEK.COM>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!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