Small languages (was Re: Lua, Lunatic and Python

Bengt Richter bokr at oz.net
Tue Dec 16 17:41:39 CET 2003


On Tue, 16 Dec 2003 06:49:46 -0600, Charles Steinkuehler <charles at steinkuehler.net> wrote:

>Paul Rubin wrote:
>> claird at lairds.com (Cameron Laird) writes:
>>> I think your decision in favor of Lua's a good one.  Guile and
>>> Scheme, from the last I saw of them, are *not* slender enough to
>>> compete.  Forth is the one other serious language that can be tiny
>>> enough to make Lua look stout; while Forth hasn't made a good
>>> impression on me as a "configuration language", that might reflect
>>> my limits more than Forth's.
>> 
>> There are Scheme subsets like SIOD which are much smaller than either
>> Guile or Lua.  Forth is a little bit too contorted for my tastes, but
>> there was once an Emacs-like editor that used something close to it as
>> an extension language.  PostScript, of course, also strongly resembles
>> Forth.  A minimal Forth can be even smaller than SIOD, but SIOD is
>> pretty small and I'd probably use something like it in preference to
>> Forth in any but the tiniest environments.
>
>I could be wrong, but it looks to me like SIOD requires a C runtime
>library to function.  One of the big attractions of using Forth (at
>least to me) is it's lack of reliance on a runtime library.  Direct
>interfacing to the linux kernel should be possible in an
>architecture-neutral manner, and the ~10K overhead of a Forth kernel is
>very minimal when compared to the ~75K overhead of SIOD (from the
>website) + the hundreds of KBytes (if not MegaBytes) of overhead for the
>runtime C library.
>
>The firewall oriented linux distribution I work with uses a shell-script
>based linuxrc to build an initial root ramdisk.  Currently this requires
>ash (~90K), busybox (~125K as configured), and ~625K for an old (and
>smallish) version of glibc.
>
>Using a forth-based solution to create the root ramdisk image would
>drastically reduce the footprint of the initial ramdisk image, remove
>reliance on a particular C runtime library (allowing folks to build
>runtime root images based on uClibc, glibc, or whatever), and provide a
>*VERY* powerful yet tiny runtime scripting/programming language for
>extending the system.
>
>The main utilities/functionality needed to bootstrap should be pretty
>simple, likely 10-15 'standard' linux commands (like mkdir, mknod, tar,
>gzip, etc), and a scripting language (forth itself).
>
>I hope to get around to implementing something like this in Forth "one
>of these days", but with 4-1/2 month old twins, my free time for
>open-source projects has pretty much evaporated, so I'm sort of hoping
>someone else beats me to it! :)
>
You might be interested in OpenBios, which is Forth-based, and apparently has/had
an IEEE standard connection (IEEE 1275-1994 (Referred to as Open Firmware)).

http://openbios.org/

and 

from http://www.OpenBIOS.info/project/progress.html:
"""
The core of OpenBIOS is a small forth virtual machine, which abstracts all the drivers and other packages from the CPU
architecture they are running on. It can thus be seen similar to what Java's VM or Perl's Parrot do. This Forth engine,
BeginAgain, can execute forth code that is entered on the command line or compiled into the dictionary and, using an FCode
evaluator written in Forth, will be able to execute the FCode bytecode representation generated by toke or other tokenizers.
Running on this virtual machine, there will basically be three interfaces: 

      the device interface, offering a comfortable API for writing platform independent device drivers, 
      the client interface, being a clearly abstracted connection between firmware and operating systems, 
      the user interface, allowing the user to interact in the boot process, debug drivers, adopt the interface to special
      requirements etc. 

There is a wide range of hardware and operating systems available already supporting the Open Firmware standard.
"""

Just one of my accumulated might-be-of-interest links, which I haven't looked at much ;-)

Regards,
Bengt Richter




More information about the Python-list mailing list