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.