Warning: this is an htmlized version!
The original is here, and
the conversion rules are here.
What is RubyFORTH?

RubyFORTH is an experimental Forth system written in Ruby with a
flexible core vocabulary.

This project has two goals. The first is to provide a simple and
elegant programming model based on ideas found in Chuck Moore's
cmFORTH. The second is to sketch these ideas in a modern scripting
language for the sake of expediency and flexibility.

As such, RubyFORTH is not intended to compete with other Forths in
terms of performance. Rather, it makes use of polymorphism, garbage
collection and platform independent libraries, asking what can be
achieved by implementing Forth at a higher level of abstraction.

While Ruby is slow (especially notable in our stack implementation),
porting the kernel to faster scripting languages is a trivial task;
the entire system can be re-implemented in a few hours. 

Language Features

[1] RubyFORTH can hook into third party Ruby libraries with ease,
    maintaining a radically simple programming interface while
    providing the functionality of hundreds of free libraries
    available both within the standard Ruby distribution and on the

[2] A cmFORTH-style concept of word immediacy through the provision of
    a twin-wordlist model: 'forth' and 'compiler'. This scheme has
    important implications for the notion of 'word'. In standard Forth
    systems, words can be marked 'immediate' to indicate their
    execution at compile time. Here, instead, we treat words
    uniformly: a word is a word. The variation in word behaviour lies
    in the inner interpreter, not with the word itself. Words situated
    within a 'compiler' wordlist are executed at compile time. If a
    word is not found in 'compiler', it is sought in 'forth' and
    compiled normally.

    This scheme vastly simplifies the concept of the word, as well as
    rendering word behaviour very explicit. Executing the 'words'
    command will tell us where word X lies -- in 'forth' or in
    'compiler' -- and hence how it will behave in the wider system.

[3] A set of tools (in the 'tools' subdirectory). Full programmes
    include an IP 'encoding' tool and a (rather slow) Forth block to
    text file conversion system. Blocks from the F83 kernel and
    cmFORTH are provided in a separate tarball for testing purposes.

[4] "Polymorphism for free". While Forth systems traditionally deal in
    integers and integers alone (though some implementations provide
    separate Floating Point stacks), RubyFORTH also treats strings as
    primary objects. As such, words like 'literal', '+' and '.'
    operate on floats, integers and strings. This is a natural outcome
    of using Ruby as our interpreter. Furthermore, we can create,
    concatenate and drop strings without worrying about memory
    allocation as Ruby will take care of Garbage Collection for us.

Why RubyFORTH?

Forth is traditionally a low-level language with very few checks in
place, allowing for rapid development of abstractions while being very
close to the machine.

Since the inception of the language, the nature of software
construction has changed. With the advent of scripting languages and
large-scale APIs (web development, GUIs, etc.), Forth systems have
gradually been marginalised from mainstream use and confined to the
embedded sector.

This project seeks to redress this imbalance by building an elegant
and minimal Forth system on top of a modern scripting language.  We
thus gain a high degree of flexibility through the portability of our
"VM" and the libraries that it provides.

The philosophy of Forth is closely tied with paradigms of simplicity,
elegance and minimalism. Historically, these concepts have been
synonymous with low-level implementations (written in assembly) such
that there is little between the programmer and the hardware.

Given the nature of contemporary platforms, Forth is no longer
'simple'; the proliferation of system architectures and varying cell
widths requires that attention be paid to the machine as much as to
the problem at hand. Furthermore, tasks that have become trivial in
modern scripting languages such as Lua, Perl, Python and Ruby remain
difficult in Forth. In writing a Forth for an abstract machine
(provided by Ruby), this problem evaporates. Solutions can be written
with attention paid solely to the conceptual problem at hand.

This project is the result of my conversations with Eduardo Ochs on
the nature of the Forth language and the maximisation of
simplicity. We both dislike elements of contemporary Forth systems as
exemplified by the ANS standard, both for the complexity of their
semantics and the complexity of their interpreters.  The criterion of
portability has replaced that of elegance.

My experiments in Frank Sergeant's Pygmy Forth illustrated
alternatives to some of the design choices present in modern
Forths. In particular, the eradication of STATE-smart words and their
affiliated problems through the advent of a dual-wordlist scheme
(derived from cmFORTH). The simplicity of Forth-79 systems was another
factor in demanding a minimal -- but powerful -- base system.

The basic idea of this project is to provide a small, intelligible and
transparent core vocabulary. Extending the system should be
easy. Hooking into external libraries should be simple, saving
programmer time and maintaining the overall simplicity of the Forth

Eduardo has been experimenting for years with minimal Forth-like
systems. It was this spirit for experiment that encouraged me to throw
together the bulk of RubyFORTH in a weekend -- a simple interpreter,
built in Ruby. The result is something of a working prototype,
demonstrating what a flexible, minimalist, modern Forth system might
look like.


Copyright (C) 2007-8, Marc Simpson