Warning: this is an htmlized version!
The original is across this link,
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 =================  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 web.  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.  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.  "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 system. 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