More comments

[Matthew Tuck]

Tanton Gibbs wrote:

> There was a recent article in IEEE software that describes the downfall
> of the JVM.  It proposes that the JVM is outdated and not nearly as
> beneficial as it appears to be.  He says that there are many new ideas
> that will replace the JVM in the near future( notice that we are talking
> about the JVM, not the Java langauge ).  I agree with what he is saying
> and will happily retype the article and send it to all parties
> interested.

As I see it what's you're saying here is to write an interpreter our
program files at first and worry about recompilers later.  What would
the bootstrap plan be then?  We still have to write native methods in
some places.  Ideally they would be minimal.

If this is what we go with, then we should still keep the JVM idea
around.  A to-JVM facility does give us the ability to work as a WWW
applet.

There's an interesting point there - any "applet" library would be
platform (ie JVM) dependent whereas most libraries you would want to be
independent.

> Not really in my understanding( which is probably wrong ), I thought
> slim binaries are never compiled, they are simply loaded onto a VM and
> executed, but the execution time is decreased because the file is so
> small it takes less time to load.

Well the file being small certainly helps but I pretty distinctly
remember in the slim binaries paper that loading and run-time compiling
was quicker than loading native code under some circumstances.  I don't
think it's really relevant anyway.  If JIT compiling gives a performance
benefit in our interpreter we could use it.

> >Yes, there is a problem here.  Libraries aren't really as much of a
> >problem though, because you'd have to give the full name unless you
> used
> >an Ada like if.

I meant Ada like "use" here, don't know why I wrote that.

> Right, but what if the A you declared from library C( C::A ) is not the
> correct type as used in the programmer's current program.  We can't be
> sure that the library is available at the time of programming, it only
> has to be available for linking.  What if someone is waiting on the
> library from the vendor who has already sent a specs sheet and then the
> programmer misuses the library variable A.

Ideally you'd have specification-implementation separation.  Ada had
this, but there was little reason for it having it.  Intelligent editors
and multiple implementations are two reasons why it is useful.

> >(a) Rehook onto the local variable.  I'm not convinced this is best.
> If
> >had lower nested classes using the higher a their semantics would
> >change.
> >(b) Give warnings that there is a conflict and do some default
> >behaviour, or ask what to do.
> >(c) Don't allow the same name to be used in nested classes as is used
> >higher up.  Some languages do this.
> 
> I'm more in favor of a combination of a and b.  Some people have reasons
> to redeclare a variable that is used in a higer up class.  They should
> definately be warned about it, but they should not be prevented from
> doing it.

Could you be more specific here?  Are you saying that they might have
existing code hooked to the outer var, and then want to rehook the code
onto an inner var?

-- 
     Matthew Tuck - Software Developer & All-Round Nice Guy
                              ***
       Check out the Ultra programming language project!
              http://www.box.net.au/~matty/ultra/