bpendlet@esunix.UUCP (Bob Pendleton) (01/13/87)
[]
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.roman@sigma.UUCP (Bill Roman) (01/15/87)
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. 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.... When writing Forth, think small. Go look at the definition of INTERPRET, there's really not much to it. Now write your own version that works the way you want. Don't go and hack complex generality into INTERPRET.
ns@gnome.cs.cmu.edu (Nicholas Spies) (01/15/87)
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
oster@lapis.berkeley.edu.UUCP (01/17/87)
Many Forth screen editors work by associating a Forth word with each
key. It would certainly be possible to build a forth reader that worked
using this approach. Systems that implement ( \ and " are already halfway
there in that they provide single character functions that advance the input
stream. Having blanks execute a function is not a problem - they just
execute the no-op function. Ordinary letters execute a function that maps
their ascii byte value onto the end of the token currently building.
Blanks check the token buffer to see if it is not empty, and if there is
something there, call INTERPRET.
I've built full readers for lisp, which allow for the evaluation of things
like: (list(+ 1 2)('3)a1"7"1a)
(For all you forth programmers who don't know lisp, in Forth this is:
1 2 + quote: 3 a1 " 7" 1 a list6
) The entire lisp reader+scanner is a page of lisp. It is comparable in
length to the Forth readers I've seen, when you take into account the
Forth code for WORD /PARSE ... down to the same low level that the lisp
reaches. But if we built something this powerful, it wouldn't be standard
Forth!
--- David Phillip Oster -- "The goal of Computer Science is to
Arpa: oster@lapis.berkeley.edu -- build something that will last at
Uucp: ucbvax!ucblapis!oster -- least until we've finished building it."