Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!pt.cs.cmu.edu!gnome.cs.cmu.edu!ns
From: ns@gnome.cs.cmu.edu (Nicholas Spies)
Newsgroups: comp.lang.forth
Subject: Re: Read tables in FORTH?
Message-ID: <7@gnome.cs.cmu.edu>
Date: Thu, 15-Jan-87 12:38:27 EST
Article-I.D.: gnome.7
Posted: Thu Jan 15 12:38:27 1987
Date-Received: Fri, 16-Jan-87 01:36:25 EST
References: <315@esunix.UUCP>
Organization: Carnegie-Mellon University, CS/RI
Lines: 48

In article <315@esunix.UUCP> bpendlet@esunix.UUCP (Bob Pendleton) writes:
>[]
>
>Has anyone tried using a read table in FORTH? ...
>
>A read table associates a procedure with each character in the character
>set. Every time a character is read the procedure associated with that
>character is executed. ...

INTERPRET uses WORD to parse the input stream using a blank as a delimiter.
WORD ignores leading blanks and moves the first and succeeding characters to
an address (usually HERE+1) and above, placing a blank after the parsed copy
of the input word. The count of (non-blank) characters is placed at HERE
making a counted string of the input, which I think is called a "token". If
the token is found to be in the dictionary (by string comparison or hash
table lookup) the code field address (CFA) of the stored token is either
compiled or passed to the address interpreter (depending on STATE) but if not
found, an attempt is made to interpret the token as a number (in the current
BASE) after which it is either pushed onto the stack or compiled after (LIT),
again depending on STATE (interpet or compile mode). If this fails the error
causes an ABORT. (The word (LIT) or its equivalent puts the compiled number
on the stack when the word the number is compiled in executes).

Bob seems to suggest making each character IMMEDIATE so that it would
parse itself or perform some other action. Unless I misread, this would tend
to create more problems then it might solve. For one thing, multiple blanks
would cause multiple interpretations...

Whatever the merits of this suggestion, Bob has touched on an important
issue: why is FORTH compilation conducted ONLY in the most primitive manner
(threading addresses)? I know of only two attempts (Tom Almy's Native Code
Compiler for PC FORTH and Jim Callahan's Auto-Optimizer for HS/FORTH) in
commercial products (plus Tom Dowling's unreleased native code compiler for
MMSFORTH) that alter the usual compilation scheme for spectacular increases
in performance (sieve in 4.4 sec instead of 31.1 sec for PCFORTH.

In staying within the traditional scheme FORTH vendors have fallen
completely behind other languages in offering an integrated, interactive
program development environment. I am deeply impressed with Lightspeed
Pascal for the Mac, which has a "make"-like utility for smart recompilation
of only those files changed sense the last compilation. You can dynamically
add source code or poke memory addresses at breakpoints during execution or
examine the names of routines and the all instansiations of variables during
recursive calls. And... it is fast.  Unless FORTH vendors respond with a
similar degree of integration (read: new compiler designs) FORTH will be
widely perceived as useful mainly as a programmable calculator and low-level
machine interface language.
Nick