Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site cadovax.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!hao!hplabs!sdcrdcf!trwrb!trwrba!cadovax!keithd
From: keithd@cadovax.UUCP (Keith Doyle)
Newsgroups: net.lang.forth
Subject: Re: Why FORTH screens?
Message-ID: <487@cadovax.UUCP>
Date: Thu, 21-Mar-85 16:35:16 EST
Article-I.D.: cadovax.487
Posted: Thu Mar 21 16:35:16 1985
Date-Received: Sat, 30-Mar-85 06:19:14 EST
References: <7349@watrose.UUCP>
Organization: Contel Cado, Torrance, CA
Lines: 29

[........]

It would appear that the reason Forth uses screens for source files,
is because of its 'incremental-compile' nature.  That is, you can
compile small parts of your source as you debug, when changes
have to be made you only have to forget down to where the
change is made, and reload from there.  With a sequential file
structure, you'd have to wind through the file till you got to where
you wanted to be, and then tell the system how much from there you
wanted to load.  You'd still want some type of random access capability
for that, otherwise it'd be slow.  In Forth's case, you are using
random access source files, and the access is left up to you, not
a source editor that would have to find what you're looking for
otherwise by searching.  Forth screens do help keep the Forth environment
faster and more interactive.  Many Forth systems bolt screen files onto
the random access capabilities of the host operating system, thereby giving
much of the advantages of both systems.

Originally, I asked much of the same questions about Forth screen files.
Now that I've used it a lot more, I think I'd hate to part with them.
I had considered writing a 'load' word to input Forth source from a
standard string file which wouldn't be hard, but I can't remember now
why I wanted it.  (However, I did modify one of the Atari Forths to
do the same with a file input from a cassette, for a freind who didn't
have a disk.)

Keith Doyle
#  {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd