Small languages (was Re: Lua, Lunatic and Python

[Julian V. Noble]

Alaric B Snell wrote:
> 
> 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

Since you are interested in state machines, may I refer you to my
article "Finite State Machines in Forth"

   http://www.jfar.org/article001.html

It is based on the tabular representation of FSMs rather than the
transition diagram representation. I couldn't think of a way to
compile a graphical representation ;-)


-- 
Julian V. Noble
Professor Emeritus of Physics
jvn at lessspamformother.virginia.edu
    ^^^^^^^^^^^^^^^^^^
http://galileo.phys.virginia.edu/~jvn/

   "Science knows only one commandment: contribute to science."
   -- Bertolt Brecht, "Galileo".