Small languages (was Re: Lua, Lunatic and Python

Alaric B Snell alaric at alaric-snell.com
Thu Dec 18 11:29:27 EST 2003


Paul Rubin wrote:
> Forth is such a contorted language though, it's best to avoid it
> unless you're desperate.

That's in the eye of the beholder - any unfamiliar type of language will 
look contorted until you learn it.

Good comments, sensible names for things, and indentation to show 
structure always help!

Compare the following FORTH:

: memory-remaining ( -- n )
   ( Count how many allocation units of memory remain unused )
    MAX-MEM @
    ALLOC-PTR @
   - ( Subtract allocation pointer from end-of-ram pointer to
       see what remains inbetween )
;

: low-memory? ( -- b )
   ( Returns true iff there is less than 1024 cells of memory left )
    memory-remaining
    1024 CELLS
   <
;

: warn-if-memory-low
  low-memory? IF
       WARN "We are running low on memory"
   ENDIF
;

...to the following semantically equivelant FORTH:

: check-mem
  ALLOC-PTR MAX-MEM @ @ 1024 CELLS - < IF
  S" We are running low on memory" WARN THEN
;

FORTH looks contorted to many people due to the postfix arithmetic 
thing, mainly. But that's not at all hard to learn, and it simplifies 
the language a lot (no operator precedence, no nonuniformity between 
'operators' and 'functions', etc).

When FORTH really shines is when you use the fact that the compiler is 
extensible to extend the language with a domain-specific sublanguage for 
your application and use that.

Eg, I am experimenting with state machines, and am planning to throw 
together a FORTH library that will allow me to write my algorithms as 
state transition diagrams.

In most languages, it has to be done like these guys are:

http://smc.sourceforge.net/

You write source code in a special state machine language, which you run 
through the external tool to generate C source, which you then compile 
into your program.

In FORTH, you can define a word such as MACHINE{ that is marked 
specially so when the compiler encounters it, it hands control to your 
own parsing code which then parses up to the matching }MACHINE 
statement, compiles the state machine (using the platform independent 
compiler backend), then returns control to the FORTH compiler. This does 
away with all the complexity of invoking the external tool; the state 
machine compiler is just imported as a FORTH library. Also, rather than 
needing to put state machines in seperate source files, you can include 
them inline, which is great for small and simple state machines used in 
only one context:

... some code ...
   MACHINE{ ... a state machine ... }MACHINE
... more code ...

So like the other guy said, how contorted FORTH code looks often depends 
on how sensible the author was in defining their application-domain toolkit.

Anyway, it's really really dangerous to say bad things about a popular 
language, OS, or editor on Usenet - it all just ends in flames :-)

ABS





More information about the Python-list mailing list