More comments

[Tanton Gibbs]

>> JVM - I still really have problems with the idea of compiling to JVM.
>> First, we would be dealing with a dynamic language that is in its
>> infancy.  Secondly, we would be dealing with a VM that was designed 
for
>> a specific language, one that is not ours.  Finally, there are many
>> differnt implementations of the JVM that don't conform to any 
standard,
>> even though SUN has a standard.  The court case will hopefully 
straigten
>> out MS, but there are still other VM manufacturers.
>
>I would think the JVM would be backwards compatible, so I don't see it
>at a major problem.
>
>We might have problems in that the JVM doesn't allow certain things to
>be done, or makes it really hard to do.  We really need someone who's
>looked at it more.  The Java Native Interface might help here.
>
>I don't know that there is a problem with different VMs, as long as
>there is a JVM for each platform that supports us.  Of course, it would
>be better if it didn't have to be downloaded.
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.

>> Here is what I recommend.  My idea is to have a platform independent
>> binary object file that could be further compiled to any platform.  
Not
>> the idea of Just In Time compiling, and not the "C" object file idea,
>> but a fully linked "slim binary" that could be compiled further to 
any
>> platform by the compiler.  Therefore, the programmer could tell the
>> intelligent editor to compile to Pentium II architecture or SUN SPARC
>> arcitecture and it will be able to do both from the same binary 
object
>> file.
>
>How does this sound.  You start with source files, one for each module.
>Then you compile each, getting compiled module files.  Then you can 
link
>a set of compiled module files.  The output is an aggregated
>platform-independent file, with inter-module optimisation if you
>desire.  Then we can implement subcompilers and VMs.

This idea is a good one.  Basically, it allows people to compile the 
binary further into machine code if desired, or to a VM if wished.

>I think we should definitely keep our options open though, as someone
>might want to write direct back-ends.
>
>I think the "Just-In-Time" compiling is pretty much the same as slim
>binaries.
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.

>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.

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.

>Say you reference an A.  The compiler looks for an A,
>sees it somewhere.  The reference is hooked onto that A.  Then you
>declare an A.  It's hooked onto the wrong variable.  There are several
>options I can think of:
>
>(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.

Tanton

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


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com