Is Factor compiled or interpreted?

Both. Factor has an optimizing compiler (written in Factor), a minimal, non-optimizing JIT compiler (written in C), and a metacircular interpreter (written in Factor). For most code, the optimizing compiler is used. However, some code won't work in the optimizing compiler (see next section) and the non-optimizing compiler must be used. When single-stepping through code in the walker (Ctrl-4 in the UI), neither of these is suitable, so a metacircular interpreter is used for more flexibility. If, by this, you mean "Does Factor produce standalone executables," the answer is no, but it can produce standalone packages; see the later question about deployment.

Why isn't my code compiling?

For Factor code to compile, it has to have a consistent stack effect that the compiler can discern, meaning it always takes a consistent number of things off the top of the stack and puts a consistent number back on. The Factor compiler can't infer the stack effect of calling quotations that it can't inline at compiletime. Another possibility is that you left out an inline. inline is needed after every combinator definition, as a hint to the compiler. A third possibility is that there is a bug; in that case, please tell us about it!

Why isn't Factor fully self-hosted?

Making Factor self-hosted would essentially mean rewriting the virtual machine in a new, low-level DSL within Factor, avoiding all high-level features. This would not offer any real advantages over using C, as it would not be interactively debuggable or replaceable. C is a suitable language for implementing low-level components.

Why aren't the C components of Factor implemented in my favorite other programming language?

C has many advantages over other programming languages. For one, GCC is heavily optimizing and readily available on almost all platforms. C is also suitable because it is very low-level and close to the machine. We need a programming language which gives us full control over the heap, since the image is saved by copying the heap directly.

Why not Factor for the Java Virtual Machine or .NET?

Originally, Factor was written in Java, and there was a compiler to JVM bytecode. But, to improve speed and the foreign function interface, Factor was rewritten in C and Factor. JFactor was abandoned in favor of CFactor. At this point, basicaly no Factor code would work in the old JFactor unmodified, as JFactor is missing several key features like generic words and syntax extension. Factor is currently natively compiled, not bytecode compiled. Removing the dependency on the JVM makes portability and distribution easier.

Why doesn't Factor use LLVM?

Until recently, Factor's assembler supported some platforms that LLVM did not. This is not true any more, but as the current architecture works, a change isn't being pursued right now. We would welcome any contributed LLVM backend, however.

This revision created on Mon, 5 Jan 2009 18:10:05 by littledan