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".
Of course, /if/ we grant that runtime checking of the sort done by Smalltalk or
Lisp also constitutes a "type system" in some sense that puts it on a par with
static type checking, then that would be another, very different, reason to
claim that Java had a hybrid type system (though, in fact, I'd rather claim
that it had two independent type systems). But that's the bigger question
point under discussion here and I wasn't trying to beg it by using the word
"hybrid".
-- chris
--
http://mail.python.org/mailman/listinfo/python-list
