Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 5/3/83; site ukc.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!mcvax!ukc!mf1
From: mf1@ukc.UUCP (M.Fischer)
Newsgroups: net.lang.forth
Subject: Re: Why FORTH screens?
Message-ID: <5008@ukc.UUCP>
Date: Sat, 23-Mar-85 14:08:56 EST
Article-I.D.: ukc.5008
Posted: Sat Mar 23 14:08:56 1985
Date-Received: Wed, 27-Mar-85 04:09:58 EST
References: <7349@watrose.UUCP>
Reply-To: mf1@ukc.UUCP (Michael Fischer)
Organization: Computing Laboratory, U of Kent at Canterbury, UK
Lines: 30
Summary: 

There is some truth to the suggestion that it maintains compatability,
but there are more important reasons for having screens.
After many years of FORTH programming, I suggest the ideal format for
storing FORTH source code would be by definition.  The least ideal
format is to have a particular set of source definitions all collected
into one file with no partitions.  I have tried both (and many others),
and still end up with screens in the end.
I think this is a consequence of the way I use FORTH.  FORTH definitions
are very transportable between applications.  Just load it in, no linking
etc.  Because of this, screens typically have one or two related definitions
with perhaps a constant or even a variable.  If the application is a
collection of source definitions it is more difficult to hunt down and
find what you are looking for, and extract it for further use.  Also 
noteworthy is that FORTH is often used where disk resources are small
and slow.  By the way, the following is a handy way to keep track of
the source block a particular word is located in, although it uses
two bytes per definition.

( Redefine :)
: : BLK @ , [COMPILE] : ; IMMEDIATE

( BLK? aaaa .... block number)
: BLK? -FIND 0= 0 ?ERROR DROP NFA 2 - @ ( Convert to SCR#) B/SCR / ;

( WLIST aaaa     lists screen with aaaa source)
: WLIST BLK? LIST ;

These could be extended to CODE VARIABLE etc.

Michael Fischer  mf1@ukc