Color Forth
Color ForthColorForth (written with "color" in red and "Forth" in green) is a dialect of ForthLanguage that uses color to replace punctuation and simplify the parser and compiler. It was designed by ChuckMoore, the original inventor of Forth. He uses it for his own work in CPU design, including his custom VLSI CAD system, OKAD. Includes own operating system, running on a bare Pentium PC. Produces extremely compact programs. Instant compile from pre-parsed source. Definitely a MinimalistLanguage.
Features:
Other resources:
See ColorForthMyths for myths about ColorForth that have been confirmed or busted.
Stand-alone! Includes operating system.
Ian, are you familiar with the storage medium/method? I'm curious to know whether it uses anything approximating a file system as we would recognize it, or if he went with the more traditional "block" method. -- GarryHamilton
colorForth uses ForthBlocks, with a utility to write a contiguous DOS file to a FAT16 floppy for interoperability (for sending a netlist off to the chip fab). Traditional colorForth uses one 1.44 MB floppy disk for persistence, but I think more recent versions also support IDE hard drives and USB memory sticks, as well as UDP packet transfer. Yes, colorForth is very "old school", treating the PC like a giant overpowered microcontroller.
It should be noticed however that ColorForth's blocks are different from classic Forth: in classic Forth, blocks are similar to block-oriented devices with (optional) caching. In ColorForth, the disk tracks that contain the blocks are read once for all at boot time, and BLOCK just converts the block number into a pointer in that preloaded memory area. The programmer may modify this memory area and use UPDATE to flush all the blocks to the disk
One thing not noted above: you get access to video graphics via a framebuffer (VESA 1024x768 and ATI cards are supported, I think), including screenshots to a PNG file. Chuck of course requires 2D graphics for his CAD layout work. -- IanOsgood
Example: http://www.colorforth.com/ide.html
In this example, black text is commentary, red text starts word definitions, and green text makes up word definitions. The top block is actual code, and the bottom block is a "shadow block" that contains nothing but comments. On real colorForth systems, comments are white and the background is black. Additional colors not seen here are yellow (for immediate commands), magenta (for variable declarations), and cyan (for uses of macros inside macros). Also, hexadecimal literals in a real system are in a darker shade of green than decimal literals.
Note how the different colors eliminate the need for punctuation between or around different types of text.
Are those colors configurable? I mean, what if someone is ColorBlind?
subsequent discussion replaced by ColorForthMyths, myth 1, 8, and 9.
Attaching a 4-bit color token to each symbol allows the compiler and editor to be much simpler, and avoids the compile/run time semantics dichotomy that complicates standard Forth systems. It's kinda like Lisp's boxed types made visible.
Language and environment discussion moved to LanguagesVsEnvironments.
I've been playing with Forth for a couple of years now, mostly for recreational purposes. In trying to learn it, I've read everything I can find by ChuckMoore and other Forth luminaries to determine what the true nature of Forth is.
It seems to me that it has changed quite a bit over the years. Chuck Moore started with it as a simple system for implementing high-level applications. As more and more other people started using it, they added all sorts of new bells and whistles. The openness of Forth makes almost any sort of extension possible.
Chuck Moore, on the other hand, has been going in a different direction. His focus is on improving efficiency of his systems. He has designed chips that directly embody Forth, so to him, Forth is really a machine language. He feels that the entire software industry has made everything way too complicated and has ignored the problem of making systems work better. Computer hardware keeps getting bigger and faster, but the software it runs is getting even bigger and much slower. All these high-level languages and abstract design methodologies have gotten in the way of simply writing code that works well.
With the release of Color Forth, the rest of us can get a better idea of what Chuck Moore's philosophy is. I've been playing with it for a week or so, and it strikes me that it is basically a sophisticated macro assembler with a lot of interactive features. It has no "operating system" beyond simply being able to boot up, accept keystrokes from the keyboard, display graphics on the screen, and read and write to the floppy drive. Even the floppy interface is simplistic, allowing one to read and write by cylinder; not by files or other high-level groupings.
It is interesting, and although I can't see myself using it for any "real programming", it is very compelling. I think Chuck is on to something here. Without easy interoperability with existing operating systems, without network connectivity, and without support for common peripherals (like hard drives), it's difficult to see how Color Forth can be more than a toy for anyone other than Chuck. But I hope I'm wrong -- it really is fun to play with. -- KrisJohnson
Toys are just products in testing.
Well, ColorForth seems to be forever in testing... Indeed. He is constantly reworking it to make his own work more efficient. He claims he is on the road to ColorForth II at the moment. ColorForth has spawned many similar dialects but dropping some of the more idiosyncratic features, such as bare x86 only, Dvorak layout, non-ASCII character representation, and so on.
Pros and cons discussed in ColorForthMyths.
Many early BASIC compilers compressed built-in BASIC tokens + their surrounding whitespace into single bytes. http://www.colorforth.com/cf.html says numbers are stored in binary (in the source code "files") -- I think might have seen a BASIC do that. But http://www.colorforth.com/cf.html also says that function names and variable names and comments are also compressed (in the source code "files") -- Has anyone seen a BASIC or anything else do that? Only for built-in keywords. -- SamuelFalvo?
Compressed an average of 5.2 bits per character -- I wonder how hard it would be to change the editor/compressor and the compiler/decompressor to use a slightly more sophisticated/efficient compressor? I'd imagine that depends entirely on how much time you want to spend on it. The compiler would need to be altered as well, since it must decompress your tokens. -- SamuelFalvo?
That sounds kind of interestingly like Simonyi's work at Microsoft on IntentionalProgramming. Which I'd like to learn more about, but info seems a bit thin on the ground -- KatieLucas
There is a striking resemblance between ColorForth and JefRaskin's CanonCat computer:
Unfortunately, JefRaskin is now deceased. However, I'm pretty sure that Moore is aware of Raskin's work, as the CanonCat was a very large-scale Forth project that was managed well enough to work. -- SamuelFalvo?
See ColorForthQuickStart for Ray's perspectives on ColorForth.
EditText of this page
(last edited July 29, 2014)
or FindPage with title or text search