[REBOL] curiosity killed the code-generator Re:(4)
From: agem:crosswinds at: 7-Aug-2000 14:11
> Hi Hen, 6-Aug-2000 you wrote:
>
> >Are there any plans to create a Rebol implementation for the Java machine?
>
Answer was finished, then i read again: Oops. a Rebol
implementation for the Java machine" or " a Java implementation
for the Rebol machine" ? i answer to the first below
(bytecode-rebol), but you seem to answer the second?
in this case, a /command-dialect for JNI would be
interesting :)
maybe Rebol changes it's "no java!" position - does
sun ignore or hate rebol? sun sponsored tcl/tk, and
Rebol is the the better one.. . With shared garbage-collector,
Rebol-aware Security and persistence (serialize a
rebol-block ready for java and back) this would be
a marked? about JPhython is said it is what Java lacked
- a perfect scripting language.. and java is a platform
too, even if virtuall?
The best reason against this is, there is no need
for anything other than Rebol in the future - but
then, why a windoze-version? if "to get into the market",
thats true for a "Rebol in Java" too.
Having a JNI-based native Rebol for very dynamic code
would be even faster of course.
Then, have you noted JNI - design? all access is done
from a interface-pointer, in princip you can can call
a JNI-lib without having a java behind it, simply
setup the "get/set value .." functions. could be a
kind of inter-language-interface. of course the called
libary must be aware of this "no real java" restrictions,
not calling any of its functions, but.. one can have
a dll which works with java or rebol or other c? write
once, plug everywhere. I thought once about that getting
troubled with all this diffrent C++-linkers. a clean
format for shared header files. a bit expendable in
declaring/calling, but - a job for a good Rebol-preprocess-Dialect
? Just dreaming :)
> Would be interesting, but the virtual machine would run _extremely_ slow.
>
Would be more interesting if fast :) even kawa (scheme)
works with "bytecode on the fly". so rebol may use
a similar approach. then there is hotspot, which should
handle don't optimize "scripts", but do optimize loops
well. And it is optimized for very "open" (virtuall,
load more stuf later, ..) style. if this style is
in code (can be extended by lots of yet unloaded classes),
but only a single class really exists yet, it does
very heavy inlining (they say). with a clever structure
a rebol2java-compiler may run well? what can't be
compiled in "native" java (aka bytecode). maybe even
better than native interpreter, if it can fix types
(knowing args must be 'integer! and that) ?
> However, the part of the JVM instruction set that I have seen is very simple
> (it's a stack machine), but AWT etc. would probably be a "no-no" because of
> speed, complexity, etc.
>
there was a "LTK" in a book which makes its GUI itself
based on very feew AWT1.0 . ("where's mouse" and "paint
this"). it worked on P100 once better faster swing
today :) and i accept a lot of slowness in beta- /view.
problem might be, if rebol.com writes /view in java,
sun gets problems of explaining why swing :) they
are so proud about it :)
> But a JVM that interprets a subset of JAVA bytecode could be interesting.
>
?? for what? Ah - you mean Rebol interprets java? here i get the _slow_ :)
> Holger from REBOL Tech. once worked on a JVM implementation for the Amiga, so
> perhaps he can tell us if such a project would be feasible. Holger?
>
> Kind regards,
> --
> Ole Friis <[ole_f--post3--tele--dk]>
>
> Amiga is a trademark of Amiga Inc.
>
Volker
