Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!ames!ucbcad!ucbvax!jade!lapis.berkeley.edu!oster
From: oster@lapis.berkeley.edu.UUCP
Newsgroups: comp.lang.forth
Subject: Re: Read tables in FORTH?
Message-ID: <2239@jade.BERKELEY.EDU>
Date: Fri, 16-Jan-87 17:33:26 EST
Article-I.D.: jade.2239
Posted: Fri Jan 16 17:33:26 1987
Date-Received: Sat, 17-Jan-87 16:37:54 EST
References: <315@esunix.UUCP> <1006@sigma.UUCP>
Sender: usenet@jade.BERKELEY.EDU
Reply-To: oster@lapis.berkeley.edu.UUCP (David Phillip Oster)
Organization: University of California, Berkeley
Lines: 22

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."