🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.misc
Article #4655

Re: OOPS

#4655
From: mnc
Date: Fri, 13 Feb 1987 16:44
57 lines
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!mnc
References: <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