Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site tekchips.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!tektronix!tekcrl!tekchips!toma
From: toma@tekchips.UUCP (Tom Almy)
Newsgroups: net.lang.forth
Subject: Re: Why FORTH screens?
Message-ID: <377@tekchips.UUCP>
Date: Fri, 22-Mar-85 10:45:01 EST
Article-I.D.: tekchips.377
Posted: Fri Mar 22 10:45:01 1985
Date-Received: Tue, 26-Mar-85 06:37:03 EST
References: <7349@watrose.UUCP>
Reply-To: toma@tekchips.UUCP (Tom Almy)
Organization: Tektronix, Beaverton OR
Lines: 20


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.