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