Small languages (was Re: Lua, Lunatic and Python

[Charles Steinkuehler]

Gustavo Niemeyer wrote:

> Hi Charles!
> 
>> 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
> 
> Oh, a Forth fan. Cool. :-)
> 
> I confess I'm not confortable with the forth syntax (at least not yet),
> but even then, I've looked into Forth as well (namingly, FICL). OTOH,
> unlike you claim below, the FICL static library is larger than Lua's
> one, and it does link with the libc runtime.

Part of the problem is there's really not much "syntax" to become 
familiar with.  Basically, everything in Forth is either a word or a 
number (or whitespace).  There are no 'syntax' characters, and the 
programmer is free to define 2#!?Lt as a word.  Combine this with the 
ability to make words that further parse the input stream...for example:

  S" <string>"

The S" is a word that takes everything following it't trailing 
whitespace (up to the final double quote) and creates a string.

Obviously, it's possible to create *REALLY* ugly Forth code, much like 
when programming in assembly (if not even worse, as the programmer can 
create arbitrary lexical sets).

Anyway, Forth's pretty easy to comprehend if you simply remember it's 
stack based (numbers get pushed onto the stack, and words get their 
arguments from and leave their results on the stack).

> Perhaps I'm looking at the wrong direction. Can you please point me
> to the Forth implementation you're talking about? I'd like to have
> a look, just out of curiosity.

There are several possabilities:

gforth: http://www.complang.tuwien.ac.at/forth/gforth/
kforth: http://ccreweb.org/software/kforth/kforth.html
pforth: http://www.softsynth.com/pforth/
eforth: http://www.lxhp.in-berlin.de/lhpe4.html
figforth: http://www.lxhp.in-berlin.de/e-lhpf4.html

The most useful 'out of the box' is probably the port of figforth from 
the lxhp.in-berlin.de site (40K as-is, with no external library 
requirements).  This site also includes lots of handy information on 
talking directly to the kernel via assembly language or forth:
http://www.lxhp.in-berlin.de/index-lx.shtml

>> interfacing to the linux kernel should be possible in an
>> architecture-neutral manner,
> 
> That's something I don't take as an advantage, for my usage cases. I'd
> rather keep away from kernel interfacing tasks (has anyone tried to
> compile something with videodev with 2.6 yet? :-). I'd rather stick with
> some minimal libc version, if needed.

I understand, but most of the things the utilities I'd like to implement 
in forth need to do (open file-handles, read/write to std-in/out, change 
directory, etc) have pretty straight-forward interfaces at the linux 
kernel level, so I don't think loosing the C library would cause too 
much programming pain.

The biggest things I think you'd miss from a standard C library would be 
stuff like timezone support, and possibly terminfo like functionality, 
but in the limited appliations I'm thinking about, these things wouldn't 
likely be missed much.  I'm not talking about trying to replace all of 
the standard linux runtime environment with Forth, just enough to make a 
workable firewall/router, set-top box, data-logger, or similar 
single-function sort of device.

-- 
Charles Steinkuehler
charles at steinkuehler.net