(im not sure if this has already been talked about but ...)
You know what would be really cool? If the Rebol compiler compiled to Java
bytecodes!
...now hold your horses...
Apart from the obvious platform benefits (which i *know* rebol already has):
1) Theres already a lot of support for Java and all related technologies
2) Rebol could utilise some of the Java popularity<->support to bring rebol
into the mainstream
3) There are native language compilers for Java bytecodes >:) (eg GCJ)
-- But its just an idea ... why can i sense a flame coming my way? :)
AndrewH
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 25, 2000 11:05 PM
Subject: [REBOL] Compiler for Rebol ? Re:(9)
> Under the heading compare and contrast, I would offer the following
> clips from the Python FAQ-o-Matic. While a popular topic for
> speculation, I don't believe whether or how the REBOL interpreter
> precompiles code has never been clarified. Of course, Carl's recent
> mention of the mysterious 'compile keyword implies something like this
> is taking place behind the scenes (and could then ultimately be
> exposed).
>
> ---
>
> 6.13. Can Python be compiled to machine code, C or some other language?
>
> Not easily. Python's high level data types, dynamic typing of objects
> and run-time invocation of the interpreter (using eval() or
> exec) together mean that a "compiled" Python program would probably
> consist mostly of calls into the Python run-time system,
> even for seemingly simple operations like "x+1".
>
> Several projects described in the Python newsgroup or at past Python
> conferences have shown that this approach is feasible,
> although the speedups reached so far are only modest (e.g. 2x). JPython
> uses the same strategy for compiling to Java
> bytecode. (Jim Hugunin has demonstrated that in combination with
> whole-program analysis, speedups of 1000x are feasible for
> small demo programs. See the website for the 1997 Python conference.)
>
> Internally, Python source code is always translated into a "virtual
> machine code" or "byte code" representation before it is
> interpreted (by the "Python virtual machine" or "bytecode
> interpreter"). In order to avoid the overhead of parsing and
> translating
> modules that rarely change over and over again, this byte code is
> written on a file whose name ends in ".pyc" whenever a
> module is parsed (from a file whose name ends in ".py"). When the
> corresponding .py file is changed, it is parsed and translated
> again and the .pyc file is rewritten.
>
> There is no performance difference once the .pyc file has been loaded
> (the bytecode read from the .pyc file is exactly the same
> as the bytecode created by direct translation). The only difference is
> that loading code from a .pyc file is faster than parsing and
> translating a .py file, so the presence of precompiled .pyc files will
> generally improve start-up time of Python scripts. If desired,
> the Lib/compileall.py module/script can be used to force creation of
> valid .pyc files for a given set of modules.
>
> Note that the main script executed by Python, even if its filename ends
> in .py, is not compiled to a .pyc file. It is compiled to
> bytecode, but the bytecode is not saved to a file.
>
> If you are looking for a way to translate Python programs in order to
> distribute them in binary form, without the need to
> distribute the interpreter and library as well, have a look at the
> freeze.py script in the Tools/freeze directory. This creates a
> single binary file incorporating your program, the Python interpreter,
> and those parts of the Python library that are needed by
> your program. Of course, the resulting binary will only run on the same
> type of platform as that used to create it.
>
> 4.93. How do I compile a Python application to a stand-alone program?
>
> Even though there are Python compilers being developed, you probably
> don't need a real compiler, if all you want is a
> stand-alone program. There are three solutions to that.
>
> One is to use the freeze tool, which is included in the Python source
> tree as Tools/freeze. It converts Python byte code to C
> arrays. Using a C compiler, you can embed all your modules into a new
> program, which is then linked with the standard Python
> modules.
>
> On Windows, another alternative exists which does not require a C
> compiler. Christian Tismer's SQFREEZE
> (http://starship.python.net/crew/pirx/) appends the byte code to a
> specially-prepared Python interpreter, which will find the byte
> code in executable.
>
> Gordon McMillian offers with Installer
> (http://starship.python.net/crew/gmcm/distribute.html) a third
> alternative, which works
> similar to SQFREEZE, but allows to include arbitraty additional files
> in the stand-alone binary as well.
>
> ---
>
> A while back, someone asked about a Java implementation of REBOL. The
> idea was dismissed in general since the REBOL binary is available for
> all Java platforms (and then some), and an imaginative Java to REBOL
> workaround was posted. Here's how the JPython group <
> http://jpython.org > justified their project:
>
> --
>
> Embedded scripting - Java programmers can add the JPython libraries to
> their system to allow end users to write simple or complicated scripts
> that add functionality to the application. Since JPython is certified
> 100% Pure Java, it can be added to an application without fear of
> compromising its ability to run on all Java platforms.
>
> Interactive experimentation - JPython provides an interactive
> interpreter that can be used to interact with Java packages or with
> running Java applications. This allows programmers to experiment and
> debug any Java system using JPython.
>
> Rapid application development - Python programs are typically 2-10X
> shorter than theequivalent Java program. This translates directly to
> increased programmer productivity. The seamless interaction between
> Python and Java allows developers to freely mix the two languages both
> during development and in shipping products.
>
> --
>
> In REBOL's case, I'd also mention that Java has support for many
> mundane features, like printing, that REBOL now lacks, not to mention
> other niceities like PDA sychronization. So if there were a
> jREBOL.class, and I ran into a feature-gap, I could put a Java wrapper
> around it and move forward.
>
> There would also be the part about distributing my application in Java
> bytecode, to hide the source.
>
> -Ted.
>
>
