🚀 go-pugleaf

> 
> Why does FORTH use screens to package its definitions?
>
 My understanding (limited) is that screens allow forth to be both
upward and downward compatable. If you do something "slick" with one
machine that isn't based on screens another computer might not be
able to work quite the same way. One of forths biggest strengths is
that not only is the language per say portable but that the operating
system is portable as well; over an incredibly wide range of machines.


 
-- 
  -"Daphnia Dave" Fetrow
    Kludgemaster  of CQS

{ ihnp4, fluke, microsof, tektronix, uw-june }!uw-beaver!entropy!fetrow
entropy!fetrow@uw-june.arpa

[........]

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

1. Easy transportability -- no need to be concerned about what the line
   delimiter is.  All implementations have exactly the same format

2. Ease of implementation -- In stand-alone environments (no O.S.), it is
   easier to write routines to access the disk in 1k chunks than it is
   to handle character streams.

3. It fits in nicely with the Forth "virtual memory" model.  Although the
   language STOIC still has BLOCKs, yet loads from blocks like an ASCII
   stream (imbedded CRLFs).

4. It really isn't that difficult to use, once you get use to it.  It
   also indirectly enforces keeping definitions short, and organizing
   your work as you do it.  By using load screens, you end up with
   tree structured programs, which are nicer than the traditional linear
   programs anyway.

5. You can have shadow screen support; its analogy with text streams would
   be very dificult to implement.

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

Why not screens??
A more serious answer is that screens are used for data storage
as well as for source. Organization of data into uniform blocks
makes access to any datum relatively simple. One can write
words which use screens as virtual memory and which function
identically to "real" memory counterparts.
   There is no problem is producing a version of FORTH
   which reads text files in a host operating system (JPL FORTH does).
   Kitt Peak VAX-Forth uses the underlying (Unix or VMS)
   operating system to organize sets of screens into files. It
   has a utility for converting standard text files into screens
   for those who want to use an external editor.
      Alternatives to screens have been discussed in FORTH circles.
		  -- John J Wavrik
		     Dept. of Math.
		     U.C. San Diego
	(ucbvax!sdcc6!ma168x)

> Why does FORTH use screens to package its definitions?

On machines with small memories and small, slow disks, screens
are reasonable, since the code to manipulate them is small.
Also, on floppies, editing screens is fairly fast, since the
editing is done in place, and an insert into the middle of a
screen has to move at most 1023 bytes.

HOWEVER, on modern computers, screens are just a pain in the you-know-what.

My FORTH system, which is an adaptation of Laxen & Perry's F83 for
68000 Unix systems, uses files.  I have not even bothered to implement
BLOCK.  I edit source code using Emacs, then load the file.
A 68000 compiles Forth so fast that it is not worthwhile to try to forget
back to where the error occurred and incrementally reload.  Instead,
I just blow away the forth process and restart it.  I can do this faster
than I can type FORGET WHATEVER.

I have modified the compiler so that it doesn't stop when it hits an
undefined word; instead, it prints an error message and compiles a
reference to a word LOSE, whose run time action is to complain and abort.
This scheme allows the compiler to find all the undefined words in a
file, without making such errors propagate through all words that
use the undefined word.

This is especially wonderful in an environment where you can run the
editor and the forth process simultaneously in separate windows,
such as inside Gosling's Emacs or in the SunWindows environment.

I have published a paper describing a proposed standard portable file system
interface, similar in spirit to the C Standard I/O concept.  The paper
may be found in the proceedings of the 1983 Asilomar FORML Conference,
along with the code to implement it under either CP/M or Unix.  The
interface spec, without the code, is also published in the Proceedings of
the 1984 Rochester Forth Conference.

By the way, my 68000 Unix F83 system will be included on the soon-to-be-
released  "Sun User Group Unsupported Software" tape.  It ports quite
easily to non-Sun 68000 Unix systems, and can also run on random 68000 boards
with a small effort.  It's public domain, so feel free to get a copy from
somebody with a Sun.

Mitch Bradley

I'm using FORTH for about 3 years on my TRS-80 Mod.I without underlying
operating system.  After zapping my Level II ROMS I burnt an EPROM
with a simple disk booter and adapted a FORTH system from a friend.
It is real fun for games and little programs, but the memory (32k)
and my spare time are too limited for any serious application.

I have only two objections to the screen concept:

1. You get a lot of fragmentation.  I am used to start new programs
   some screens away from the last used screen to provide space
   for changes to the older programs.  This can be very annoying
   if you use up to 30% of the disk for empty screens !

2. Since I don't have much space, I tend to sqeeze my definitions
   on the screens.  It's awful, but it's the only way to use space
   economically.

I would like to have some expandable concept:

   Named files which consist of screens internally.  Maybe there
   should be two file types:  Raw block files and text files.
   Text files have line-oriented text and should only be accessed
   by the editor and the load word.  Block files are for data,
   but they are also editable and loadable.
   Every block file would have screens 0..N and should be used
   for the data of one program.  Common routines for random
   generator, game subroutines etc could reside in their own files.

What do you think of it ?

	Hans-Martin Mosner
	Universitaet Dortmund (Germany)
	    ihnp4!hpfcla!hpbbn!unido!hmm 
	{decvax,philabs}!mcvax!unido!hmm