Chris Uppal wrote: > Marshall wrote: > > [me:] > > > But, as a sort of half-way, semi-formal, example: consider the type > > > environment in a Java runtime. The JVM does formal type-checking of > > > classfiles as it loads them. In most ways that checking is static -- > > > it's treating the bytecode as program text and doing a static analysis > > > on it before allowing it to run (and rejecting what it can't prove to > > > be acceptable by its criteria). However, it isn't /entirely/ static > > > because the collection of classes varies at runtime in a (potentially) > > > highly dynamic way. So it can't really examine the "whole" text of the > > > program -- indeed there is no such thing. So it ends up with a hybrid > > > static/dynamic type system -- it records any assumptions it had to make > > > in order to find a proof of the acceptability of the new code, and if > > > (sometime in the future) another class is proposed which violates those > > > assumptions, then that second class is rejected. > > > > I have to object to the term "hybrid". > > > > Java has a static type system. > > Java has runtime tags and tag checks. > > It has both, agreed, but that isn't the full story. I think I explained what > I > meant, and why I feel the term is justified as well as I can in the second > half > of the paragraph you quoted. I doubt if I can do better. > > Maybe you are thinking that I mean that /because/ the JVM does verification, > etc, at "runtime" the system is hybrid ? > > Anyway that is /not/ what I mean. I'm (for these purposes) completely > uninterested in the static checking done by the Java to bytecode translator, > javac. I'm interested in what happens to the high-level, statically typed, > OO, > language called "java bytecode" when the JVM sees it. That language has a > strict static type system which the JVM is required to check. That's a > /static/ check in my book -- it happens before the purportedly correct code is > accepted, rather than while that code is running. > > I am also completely uninterested (for these immediate purposes) in the run > time checking that the JVM does (the stuff that results in > NoSuchMethodException, and the like). In the wider context of the thread, I > do > want to call that kind of thing (dynamic) type checking -- but those checks > are > not why I call the JVMs type system hybrid either. > > Oh well, having got that far, I may as well take another stab at "hybrid". > Since the JVM is running a static type system without access to the whole text > of the program, there are some things that it is expected to check which it > can't. So it records preconditions on classes which might subsequently be > loaded. Those are added to the static checks on future classes, but -- as far > as the original class is concerned -- those checks happen dynamically. So > part > of the static type checking which is supposed to happen, has been postponed to > a dynamic check. It's that, and /only/ that which I meant by "hybrid".
That's fair, I guess. I wouldn't use the terms you do, but maybe that doesn't matter very much assuming we understand each other at this point. Marshal -- http://mail.python.org/mailman/listinfo/python-list
