[REBOL] Compiler for Rebol ? Re:(9)
From: news:ted:husted at: 25-Sep-2000 9:35
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.
