Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

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