From: Godmar Back (gback@cs.utah.edu)
Date: Fri Jan 29 1999 - 14:11:47 EST
Forwarded message:
>From max@immsp.kiev.ua Fri Jan 29 11:28:27 1999
Sender: max@simple.immsp.kiev.ua
Message-ID: <36B1FB43.C76E86C4@immsp.kiev.ua>
Date: Fri, 29 Jan 1999 20:17:39 +0200
From: Maxim Kizub <max@immsp.kiev.ua>
X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.0.35 i586)
MIME-Version: 1.0
To: Godmar Back <gback@cs.utah.edu>
Subject: Re: Type parametrization & closures/method references
References: <199901291618.JAA26646@sal.cs.utah.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Godmar Back wrote:
>
> Maxim,
>
> I consulted with the kaffe core team and we decided to not apply
> this patch.
Could you be more specific with "core team". Tim? Piter? Who?
> The main reason is that the goal of the kaffe project is to create
> a free clone for Java, and not for extensions of Java. At this point,
> we have enough trouble getting Java right, as you can witness yourself.
I do not see how this may affect pure java. All additions are
#ifdef-ed, there will be no change in kaffe, if that EXTENDED_VM
macro is not defined.
> While you phrased your patches as #ifdef EXTENDED_VM, many of the
> patches to files in kaffevm are indeed specific to a given VM extension,
> namely the one you propose.
You mean what? There are two kinds of changes - new bytecode
and new signatures.
New bytecodes are not kiev-specific at all. They are simply
generalized support for effective closures and method references
implementations. There is nothing specific with this instructions.
Any, any other language that compiles with JVM bytecode target
can use them, they sutable for procedural languages like
kiev or pizza, as well as for any other langauge that supports
closures - SmallTalk, scheme, etc.
Changes in signatures... Well, signatures for parametriezed
types are common for kiev and pizza. Anyway, there must be
some kind of extending signature to support parametrization.
Signatures for method references are general purpose.
I just neede to have one, I selected this form. And there is
nothing specifical with it for kiev. Just signatures
for method referenses.
And last signature - for prolog-rule methods... In fact,
'R' means (currently) exactly the same as 'Z' - i.e. boolean
type. I may remove it now. But in future I wish to
add support for rules, so, why not help me?
If any other extension will require new signature - I'll
add support for this signature in kiev compiler, to
be compatible with kaffe. Why not?
> Plus, there's no reason that the files in kaffevm/ext should be held
> in the kaffe CVS repository, as they are specific to kiev's approach
> as well.
The reason is simple - why peoples need to get sources
from different CVS repositories, if this is for one
program? I do not ask you or someone else to patch
these sources or be compatible with them. When you'll
make changes - I'll change these ext/* files.
> Other people have also developed extensions to Java. For instance,
> Alexandre developed Guarana, a mechanism that extends the VM with
> reflection mechanism. We also have not included those.
Ok, I'll contact him, thanks.
But about "we also" - didn't I asked about these changes before?
There were no discussions in kaffe core team when I asked first
time? IMHO, it whould be more polite to say me about
rejecting these changes before I started to do them :-|
> On the other hand, we are interested in keeping you as a contributor
> to kaffe, and we are therefore interested in making kaffe as suitable
> as possible for your research. For this reason, we are willing to
> accept any changes that would help you, and other people developing
> their own extensions, but which are not kiev specific.
This changes ARE NOT KIEV SPECIFIC. Period.
I had plans about making KIEV SPECIFIC changes to
add support for prolog engine of kiev, but even for
them I wish to make them as sutable for others (like
scheme and other languages that uses tail-recursion)
as possible. But current are not specific for kiev.
> If I were you, I'd put up my own distribution. Kaffe is free software,
> and allows you to do that. However, because of the GPL, your derived
> work will have to be GPL'ed as well.
I do not think this is a problem ;-). I mean GPL. But splitting
a project is really the problem. It's the last
thing I wish to do.
> Another possibility you have is build your extended kaffe in a separate
> library, such as libkaffekiev.a, and link the main program with
> an existing kaffe installation like so -lkaffekiev -lkaffevm.
You see the patches, and you know that this is impossible.
How, to hell, can I patch constant pool without a call to
my method from exactly defined place? It's not an additional
native class method, it's the virtual machine functionality.
> I hope you understand our reasoning on this matter.
Sorry, I do not understand reasons. But this is your
decision. I can only leave, or split the project, or
try to change your mind... I'd better start with last
approach.
So, why do you decided to make JVM ?
What's so good with java? Why do you like it?
One possible answer is that Sun Inc. is the best
firm on the earth. Really?
Another possible answer - is that java is
one of the best by design and support
_platform_independed_environment_. I think,
this is the real answer. I'm not talking about
java as a language. Holly wars like C vs Prolog
and others not for me. There is no better
lenguages - all of them are best for their
own pirposes of programer prefearences.
I'm talking about JVM as environment for
running programs. And JVM is one of the best.
It's safe, it's secure, it has good
libraries and it was designed with future
in mind.
The only probkem with JVM is that it's Java(tm)
specific.
Look. There is no difference for programming
language for wich target it will be compiled.
C or Pascal or Lisp or ... programs runs
pretty happy on any computer - on i386, on
motorolla, on power pc, on sparc, on alpha
processors - everywere. All of them needs
support for common operations - arithmetic,
conditional and unconditional jumps, method
calls and so on. Some of them uses special
things like "virtual tables", "exceptions",
"closures", "tail-recursion" and so on.
But they able to emulate them on existing
hardware. But it's impossible to emulate
something on JVM bytecode, since it's Java(tm)
specific. It has support for arithmetic,
jumps and so on. this covers 99% of needs
of other languages. But alas, it's impossible
to implement the rest 1%. Or they need to
implement the whole code completly uneffectivly.
For example, imagine that JVM do not have
support for monitor_enter/monitor_exit ?
Can you imagine how complex will be
implementation of sinchronized statement
for those languages, that have it?
I selected JVM as good environment. belive me,
it absolutly does not metter what kind
of code I whould generate - for java VM, for
SmallTalk VM, or for another VM.
99% of code is the same, it's an unintresting
detail, that opc_add is an instruction number
96 and not 88 or 77. But when I get the
situation, when there is _no_ instructions,
and there is _no_ way to implement it
effectivly - this is _very_ intresting
detail.
I just wish to make JVM as "sutable" for
other languages, as JVM is sutable for
running programs on other hardware.
You like JVM because it allows run programs
on different hosts, simplifying the life
of programers and users, and you do not like
any modifications to make JVM sutable to execute
programs written with different languages?
I simply can't understand this.
Well, I did a try to change your decision.
How good it was ? ;-)
Regards
Maxim Kizub
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:53 EDT