>From Documentation for Atari CoinOp Forth and Swarthmore Extensions
<https://ia601205.us.archive.org/17/items/AtariCoinOpFORTHAndSwarthmoreExtensions/Atari_coin-op_FORTH_and_Swarthmore_Extensions.pdf>
:
HOW TO WRITE GOOD FORTH
FORTH suffers from a combination of bad press arid bad programmers. It is
actually easier to write good FORTH than good anything else, since it is
flexible, imposes few restrictions, and extracts no penalty for short
programs, (Short programs, incidentally, are where it's at - breaking
things up into small, sensible, lucid pieces is a key to good programming).
*Why write good FORTH? *
Good code is faster to write, if you consider total time, since it comes
from clear thinking and good organization, arid it is much easier to debug.
You can understand and modify good code in amazingly shorter time*
Finally, you're much more employable if you write good code* Should a
prospective employee tell me that he or she prides him or herself in
writing good, clear, maintainable, well-documented FORTH I would, after
picking myself up off the floor, endeavor to hire the person or. the spot.
*How to write good FORTH: *
You need to (1) know what good FORTH is, (2) discipline yourself to write
it. Item (1) will be addresed[*sic*] next. For (2), I've observed that a
few thoughtful rewritings of a reasonably sized piece of code will not only
help a decent programmer understand what good code is, but will also
establish the necessary habits so that writing passable code becomes almost
automatic, and good code a distinct possibility.
*What is good FORTH? *
Good FORTH consists of short, well thought out pieces. A word should rarely
take up more than half a screen. If you use more than that, see whether you
can break up the word into smaller, more coherent pieces* A good FORTH word
is one which is easy to understand, and which you might be tempted to use
again elsewhere.
Good FORTH is vertical, not horizontal. That is, there are few words per
line and the lines are left-indented in an intelligent fashion. DOs and
LOOPs, BEGINs and UNTILs, IFs, TH£Ns, and ELSEs, etc. are all left
justified, with inner groupings to the right of outer ones. Take a look, at
the Swarthmore source code to see what this means.
Each line should contain no more than a single idea.
A comment accompanying each word should show its effect on the stack,
preferably with helpful mnemonic symbols for the stack, elements.
Words should be liberally sprinkled with comments. More lengthy comments
can be put after the "-->" or ";S". The best code is almost
self-documented.
The first line of a screen should consist of a comment which describes the
contents of the screen. You should rarely start with more than half a
screen full of code.
Will you go broke buying the number of disks necessary to write good FORTH?
Hardly. Even in this expansive forn, FORTH gets you a lot of mileage.
Moreover, few items connected with computers are as cheap as disk space.
Finally, truth to tell, revisions and reworking usually result in screens
filling up more than the minimal recommended (starting minimally gives you
room for such expansion).
FORTH is supposedly a "stack oriented" language, but the programmer should
not be stack oriented. Juggling several elements or. the stack can cause a
surprising number of errors. In almost all situations, it's much clearer
and leads to many fewer errors if you introduce sensibly named variables.
It is hard to find a situation when such a practice will measurably slow
down a program. It is possible to juggle stack elements by sending them to
and from the return stack (it's possible to do lots of wild things in
FORTH), but it's usually just not worth it.
If you simply must play with several items or. the stack, you're probably
best off making up special stack manipulation words. If a word deals with
several items on a stack, I've also found it very helpful to put in full
comment lines within the word which show the stack, changes in clear
mnemonics[*sic*],
Well-thought-out names can contribute immensely to good code. It's worth
spending tine making up useful names (self-documenting code, again). One
helpful approach is to try to name *what* the word does, not *how* it does
it. Don't use an unidentified nunber in a word. Either identify it in a
content or define a constant (with a good name) arid use it in the code.
Avoid abbreviations when you're writing code. The extra typing is trivial
and the clarity introduced is considerable. It's fair and reasonable to
introduce abbreviations in a testing/debugging session, however.
*Is our code good?*
It varies. It's getting better. At first we committed the negation of the
above ideas. Look over our source code and see what you like and what is
clear. There are probably 8 different prograMMers represented on the
SwarthMore disks, so there are lots of different styles, ideas, arid
approachs.
Further thoughts or. writing good FORTH are to be found in Leo Brodie's
*Starting
FORTH*.
On Thursday, June 13, 2024 at 6:19:31 PM UTC-4 tbp1...@gmail.com wrote:
> It was remarkable how much faster a 2 MHz Z80 was than an early PC with
> the 8088 at nearly 5 MHz. I was able to make a direct comparison because I
> had a FORTH program I used all the time on a 64k Z80 machine. When I got a
> PC I was able to find a 8088 FORTH system. FORTH was written with a small
> core of assembler and then all the other FORTH instructions were written
> using that fast core. So FORTH for the two machines was as nearly
> comparable as you were going to get.
>
> The PC version running our FORTH code on a 8088 machine was wretchedly
> slow compared to the Z80 version. The PC version only caught up when the
> AT came out with an 8MHz processor.
>
> On Thursday, June 13, 2024 at 5:08:29 PM UTC-4 jkn wrote:
>
>> I never used TECO on a PDP (PDP/11 in my case), but I did use PMATE
>> ('Michael Aaronson's Text Editor, IIRC) on an early S-100 Z80 computer, and
>> that was heavily 'inspired' by TECO, I believe. working with the 'command
>> syntax' was great fun, as was customising the editor to work with your
>> graphics card driver.
>>
>>
>> On Thursday, June 13, 2024 at 8:45:01 PM UTC+1 tbp1...@gmail.com wrote:
>>
>>> After reading the link, I see I never got near anything like TECO.
>>>
>>> On Thursday, June 13, 2024 at 3:17:49 PM UTC-4 David Szent-Györgyi wrote:
>>>
>>>> TECO for the PDP/8 was available under OS/8. The Wikipedia article on
>>>> TECO <https://en.wikipedia.org/wiki/TECO_(text_editor)> is a nice
>>>> summary. There you can find links to Web pages on TECO, including one by
>>>> the originatoer of TECO and the GitHub repository for TECOC, a
>>>> reimplementation in C for Windows, macOS, and LInux.
>>>>
>>>>
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/leo-editor/088d4f3c-f696-499f-a0e4-87f48377d36cn%40googlegroups.com.
