NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/lang/forth/3762

Text File | 1993-01-04 | 7.4 KB | 185 lines

Newsgroups: comp.lang.forth
Path: sparky!uunet!starnine!mikeh
From: [e-mail] (Mike Haas)
Subject: Re: Documenting
Message-ID: <[e-mail]>
Sender: [e-mail] (Mike Haas)
Date: Tue, 5 Jan 1993 00:42:10 GMT
References: <4226.UUL1.3#[e-mail]>
Organization: StarNine Technologies, Inc.
Lines: 173

Believe it or not, I don't want to start another screens-vs-text files
flame war, but I get a little frustrated when I see people both moaning
"Why isn't Forth more popular" and others arguing "screens are great!".

 I really wasn't going to post anymore on this topic, but Brian's post
 below was something I couldn't resist because many of the "desirable"
 things he sez SHOULD be included in screen editors by vendors can be
 done with JForth on the Amiga with the supplied TEXTRA editor, a
 GUI-based text editor that uses the Amiga ARexx system to communicate
 with JForth.

 To be more specific...

In article <4226.UUL1.3#[e-mail]> [e-mail] (ForthNet articles from GEnie) writes:
>Category 3,  Topic 3
>Message 17        Fri Jan 01, 1993
>B.DUNN5 [Brian]              at 23:09 EST
>
>
> 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.

TEXTRA allows any sub-section of a file to be interpreted (or compiled)
by dragging the mouse over the text to be processed.  Once it is
"selected" in this way, a single key press sends the text to the
JForth interpreter.

>
> > 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,

As described above, You can do this with TEXTRA and JForth (or
reload two or THREE definitions... it's up to you).

>word by word execution,

Also do-able from the TEXTRA editor.

> useful interaction with a Forth terminal program,

Using the Amiga's AREXX facility, you could have TEXTRA, JForth and
an ARexx-compatible Amiga terminal program ALL WORKING TOGETHER (or ANY
ARexx-compatible application :-)

>have multiple copies
> executing at a time,

TEXTRA allows you to have any number of text files open at one time...
puts each in their own window.

>and all usually with much less memory, time, and
> operating system overhead.

As I have 6 Meg and a 25Mhz 68030 in my Amiga, no problem.

> > 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

JForth allows you to INCLUDE text files.  The above becomes...

INCLUDE editor  INCLUDE terminal  INCLUDE extensions  INCLUDE decompiler

...IF you have files of those names.  (In other words, it uses the
native file system as the "directory"... why re-invent the wheel
when every platform has a file system?)

Also, JForth even allows you to conditionally compile a given file
if needed.  For example...

   INCLUDE? SQUARE MY-MATH-UTILS

...will only compile the file MY-MATH-UTILS if the word SQUARE
can't be found in the dictionary.

>
> 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.

I did this for the last screen-based system I built (about 8 years ago).
It was the only way I found to get major work done, reliably backup
source, share source.  I had 2 5 Meg cartridge hard disks on that machine
and it was next to IMPOSSIBLE to manage 10,000 screens by number!

It WAS great!  FInally, I could copy files, maintain separate directories,
keep file creation & modification dates, USE FILENAMES!!!  I can't express
enough how much more USEABLE that system was after adding a file system.

>
> 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.

TEXTRA has programmable function keeys that can be set up to
launch it's own script files, send any message to any running
Amiga program (including JForth), basically kick off anything
you want.


>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.

Sounds really cool, but none of it requires a built-in editor with
screen files.

Text editors are no longer closed, canned programs.  They enjoy the
trends of the industry in the last 20 years toward open systems,
and can interface to many various and sundry entities.

TEXTRA's interface to JForth needs to be seen to be appreciated.
Even when you've pressed that single key, telling JForth to
compile the current file, if an error occurs, JForth tells TEXTRA
the file line number, and the editor highlights that line and
puts up an error message.

TEXTRA v1.11 is provided free with JForth.  It is a freeware program
that can be passed around and used for general text uses, like letters,
book reports, etc.

In the latest TEXTRA package (v1.13), there is now the capability
to interface with the HSPascal compiler, replacing their own
integrated text editor.

TEXTRA is written in JForth, and is a standalone, CLONEd program.

I guess this post has turned into another shameless plug.
Sorry, but it really did apply to the matter at hand.

For info about JForth, contact...

   Delta Research
   P.O. Box 151051
   San Rafael, CA. 94915-1051
   [phone]

   direct e-mail to:

   [e-mail]   OR
   [e-mail]

If you read this far, thanks.