eppstein@tom.columbia.edu.UUCP (02/14/87)
In <158@m10ux.UUCP>, mnc@m10ux.UUCP (MHx7002 ) writes: > 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. Pardon my obtusity, but I still don't see it. Why can't you have a language that is (by your definitions) statically typed, so you know that this use of X is an integer, but dynamically bound, so you don't know whether it refers to the same place as that other use of X (also known to be an integer). If you see a string use of X you of course know they're different, but that doesn't mean that aliasing among the integer uses is known. Not that I know of any such language... -- David Eppstein, eppstein@cs.columbia.edu, Columbia U. Computer Science Dept.
gore@nucsrl.UUCP (02/18/87)
/ rentsch@unc.UUCP (Tim Rentsch) / 3:33 am Feb 15, 1987 / > [...] by adding "type" declarations to a Smalltalk program, it > is possible for the compiler to check "types" at compile time, and > guarantee that 'message not understood' errors will not occur at > runtime. [...] > > On the other hand: even in the situation described in the paragraph > above, it is not possible to know which method body will be bound to > a given message (indeed more than one method body may be bound, at > different times, to any particular message send). Even though we > know at compile time that 'message not understood' errors cannot > occur -- in other words the code is statically checked -- we do not > know (cannot know) which methods will be bound to which message sends. [...] It seems hard for some people with Smalltalk way of thinking about objects and messages (and this includes myself) to see how you could do what you describe. Could you give an example? Just invent a typing syntax for Smalltalk, and demonstrate on some short program sections. Jacob Gore Northwestern University, Computer Science Research Lab {ihnp4,chinet}!nucsrl!gore
crowl@rochester.UUCP (02/20/87)
For those of you interested in statically bound types and dynamically
bound implementations (methods) see:
Craig Schaffert, Topher Cooper, Bruce Bullis, Mike Kilian, Carrie Wilpolt;
"An Introduction to Trellis/Owl"
ACM SIGPLAN Notices 21(11), 9-16
November 1986
Andrew Black, Norman Hutchinson, Eric Jul, Henry Levy;
"Object Structure in the Emerald System"
ACM SIGPLAN Notices 21(11), 78-86
November 1986
Andrew Black, Norman Hutchinson, Eric Jul, Henry Levy, Larry Carter;
"Distribution and Abstract Types in Emerald"
IEEE Transactions on Software Engineering
December 1986
The two Emerald papers are similar, but the second is probably better for
this topic.
--
Lawrence Crowl 716-275-5766 University of Rochester
crowl@rochester.arpa Computer Science Department
...!{allegra,decvax,seismo}!rochester!crowl Rochester, New York, 14627rentsch@unc.UUCP (02/23/87)
In article <4000007@nucsrl.UUCP> gore@nucsrl.UUCP (Jacob Gore) writes: > / rentsch@unc.UUCP (Tim Rentsch) / 3:33 am Feb 15, 1987 / > > [...] by adding "type" declarations to a Smalltalk program, it > > is possible for the compiler to check "types" at compile time, and > > guarantee that 'message not understood' errors will not occur at > > runtime. [...] > > > > On the other hand: even in the situation described in the paragraph > > above, it is not possible to know which method body will be bound to > > a given message (indeed more than one method body may be bound, at > > different times, to any particular message send). Even though we > > know at compile time that 'message not understood' errors cannot > > occur -- in other words the code is statically checked -- we do not > > know (cannot know) which methods will be bound to which message sends. > Could you give an example? Just invent a typing syntax for Smalltalk, and > demonstrate on some short program sections. I know this will sound like a lame excuse -- but could I refer you to the 1982 POPL paper on the subject, (by Alan Borning and Dan Ingalls)? This paper has all the dope, examples included, and notes from the implementation. If you have more questions (or if you can't find the paper), let me know and I will post an example. [Sorry I'm too burned out to post one right away.] cheers, Tim