Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!utah-cs!utah-gr!uplherc!esunix!bpendlet
From: bpendlet@esunix.UUCP (Bob Pendleton)
Newsgroups: comp.lang.forth
Subject: Read tables in FORTH?
Message-ID: <315@esunix.UUCP>
Date: Tue, 13-Jan-87 15:41:24 EST
Article-I.D.: esunix.315
Posted: Tue Jan 13 15:41:24 1987
Date-Received: Thu, 15-Jan-87 04:28:03 EST
Lines: 39

[]

Its been a while since I've worked with FORTH, so if what I'm talking about
is old hat, just point me at some references and I'll go away happily.

Has anyone tried using a read table in FORTH? As I recall, FORTH scans its
input, accumulating characters into a token until a blank is encountered.
When a blank is found the accumulated characters are processed. This means
that the shortest sequence of characters that can cause FORTH to take some
action is two characters long. That is, a one character name followed by a
blank.

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. The actions of the FORTH scanner can be implemented
by proper selection of the procedures associated with each character. Most
characters would be associated with procedures that store the character in a
buffer, the procedure associated with blank could look up the contents of
the buffer in the symbol table.

Having a read table would allow several one character functions to be
invoked without having to see the trailing blank. I think It would make
FORTH even more nicely extendable than it is now. Of course, input using a
read table could be implemented on top of an existing FORTH.


-- 
-- 
               Bob Pendleton
               Evans & Sutherland Computer Corporation

UUCP Address:  {decvax,ucbvax,ihnp4,allegra}!decwrl!esunix!bpendlet
Alternate:     {ihnp4,seismo}!utah-cs!utah-gr!uplherc!esunix!bpendlet

Riskier than RISC, Ciskier than CISC, the time for microcode is now.

---

I am solely responsible for what I say.