Path: utzoo!attcan!uunet!know!sdd.hp.com!uakari.primate.wisc.edu!uflorida!mlb.semi.harris.com!forth.mlb.semi.harris.com!rcv
From: rvn@forth.mlb.semi.harris.com (Rick VanNorman)
Newsgroups: comp.lang.forth
Subject: Files VS Blocks, a compromise
Message-ID: <1990Oct15.152050.16614@mlb.semi.harris.com>
Date: 15 Oct 90 15:20:50 GMT
Sender: news@mlb.semi.harris.com
Organization: Harris Semiconductor, Melbourne FL
Lines: 54
Originator: rcv@forth.mlb.semi.harris.com
Nntp-Posting-Host: forth.mlb.semi.harris.com

The current controversy over FILES vs BLOCKS has bubbled to the top of
the topics list again.  Without trying to pound either viewpoint into
the ground, here is a modest proposal that I believe represents a
compromise between the two positions.

The arguments have been made, pro and con, for each of the two
approaches to handling Forth mass storage.  Each of the arguments has
merit.  I will not attempt to describe, summarize, or otherwise butcher
these arguments.  Let me simply assume that I want to use files, but I
want as many of the benefits of using blocks that I can get.

I propose using a virtual program page model for files -- each page
being roughly equivalent to an almost free-format block.  The limits on
page size are arbitrary, but a size equal to one printed page seems
reasonable, say 80 columns by 60 lines (4800 bytes).  Writing a page
editor such as this is relatively trivial; although not quite as easy as
a block editor, it is still within the range of a 4K byte extension in
most Forth systems.  Text could be imported into the editor from normal
Ascii files -- the import procedure would take tabs, crlf, etc., and
put them into the fixed size buffer, with all white space occupying a
character position just like in blocks.  Editing would be simplified by
this model, with the only major extension over block editing being the
requirement to scroll the visible portion of the page up and down.

"But wait!" you shout, "One 80 x 60 page isn't enough!"

I further propose that files consist of multiple pages, each delimited
by a simple comment character string, or perhaps by the page feed
character (0CH) embedded in the file (implementation detail, irrelevant
to the current discussion).  My own scheme is to use a string such as
" \-----" to delimit pages.

When you edit a file, the editor will import text from the specified
page while noting the start and end offset within the file of the page.
When editing is complete, the edited page will be re-inserted into the
file.

If you need more space in a page, simply insert the page delimiter into
the edit image (in effect, splitting the page into two), flush the page,
and re-edit.  The editor only cares about what the text it reads looks
like, not about what it writes.  If you want to combine two pages, simply 
delete the delimiter at the top of the current edit image and flush.  The 
current page will be combined with the previous page.

Since this editor can be integrated into a Forth environment, partial
loads of a text file are now simple, turn-around in the
edit-compile-test loop is very quick, and an external editor may still
be used anytime it is needed.

This approach will (I believe) give all the versatility of both blocks
and files to a self-contained Forth environment.

I am still in the process of implementing this scheme in my current
environment, and would appreciate any and all feedback.