What is Expressiveness in a Computer Language

[Marshall]

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