Newsgroups: comp.lang.forth
Subject: Documenting
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Date: 2 Jan 93 12:02:06 GMT
Organization: EIEI-U

Category 3,  Topic 3
Message 17        Fri Jan 01, 1993
B.DUNN5 [Brian]              at 23:09 EST
 
 
 > Screen files also allow loading individual screens,
 > where text files usually require a total reload to finish
 > compiling after an error in the middle of the file.

 A decent file text editor would allow a single keypress which would
 backup the cursor to the start of the current definition ( back until
 finding a line with a non-whitespace character in the first column ),
 start loading at that cursor position, and when a new word is
 defined, any previous definition with the same name would be patched to
 call the new definition.  The load would then stop after the new word has
 been defined.  The result is a single key redefinition of one word without
 loading anything before or after.

 > I don't care how cool a Forth SCREEN editor you have... there are
 > much better ones for text files.

 Every vendor should provide a spiffy editor built with and interacting with
 Forth, regardless of screens or files.  It can be more useful than calling
 an external editor from Forth via the operating system.  When it is
 built in, you can do single definition reloads, word by word execution,
 useful interaction with a Forth terminal program, have multiple copies
 executing at a time, and all usually with much less memory, time, and
 operating system overhead.

 > I hope I never again have to wind my way trough something like...
 > 5 LOAD 8 LOAD 23 LOAD 100 110 THRU 56 LOAD 13 LOAD etc. etc. etc

 A good screen oriented system will often have some kind of directory.  The
 above could become:
   dload editor   dload terminal   dload extensions   dload decompiler

 It is possible to build a pseudo-file interface over a blocks system, with
 block allocation tables and filenames.  Each file would really be a set of
 physical blocks organized into a virtual sequence starting from virtual
 block 0.  You would have fileIDs and tables to map virtual to physical.
 To carry the concept out a little more, you could have the file be one
 big block 64 characters wide and of unlimited number of lines.  The editor
 would scroll through the entire file without 16 line page breaks.

 > There are things, that files are very unsuitable for. consider a
 > sextet index of a Monte Carlo Simulation Program:
 >        420 \ Polymers - Main                                PSP 22/11/92
 >        421 \   Polymers - local                             PSP  3/06/92
 >        422 \   Polymers - contd.                            PSP 30/05/92
 >        423 \ Energy discretization                          PSP  2/11/92

 An indexer could be made on a file system by having a printout only of
 lines where there is a non-whitespace character or even a special
 character in column 1.  If this concept is applied to an editor, you could
 have a keypress activate an outline mode, where only these lines appear on
 the screen, you scroll to the section heading you wish to edit next, then
 zoom back into the source code.

 > Even though the good editors have their
 > languages, not is a flexible as FORTH is. They are pretty narrow too.
 > On the contary one has the entire source of his editor in FORTH and
 > implements whatever functions he considers usefull. And one ends up
 > with a highly tuned to himself editor. 

 Imagine an editor or terminal program built with Forth, where you may
 define a function key to fire off a definition you provide, with all the
 power of Forth available for that action, plus access to common editor and
 terminal functions.  This was put to very effective use with
 an online starship game, where the other guys were using their simple
 terminal macros to automatically raise shields and fire weapons, whereas
 a single keypress on my own machine fired off little a Forth program which
 automatically raised shields, launched decoys, started a sequence of
 defensive maneuvers, scanned for the enemy, parsed their direction and
 range from the input stream, immediatly selected and fired the
 appropriate weapons for that range, monitored damage, and hit jammers and
 dropped mines when it was time to bug out and run.  The response time,
 parsing of useful information, and decisionmaking based on that information
 made it the ultimate macro game program.  All using a simple built in
 terminal which could fire off real Forth words from its function keys, with
 access to useful functions provided for later use.  The same works with
 an editor.

-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us