stever@tree.uucp (Steve Rudek) (01/04/90)
The following entry is derived from a mail response I wrote to Mitch Bradley concerning screens vs. standard files. He recommended I investigate the browser/editor features of a commercial Forth 83 system called "fifth". I intend to do that, since I just ordered an MS-DOS "shareware" implementation from them for only $10 (and you can, too, by calling (409) 696-5432). Anyway.... ----------- Mitch said: > Fifth's basic editing unit is a definition, and you can > change a definition and recompile just that one. It navigates > around the "network" of definitions in a hypertext-like way. and I eventually got out my soapbox and said: -------- THE FUTURE OF FORTH IN THE PC AND WORKSTATION ENVIRONMENT (at least) IS WED TO HYPERTEXT. Specifically, Forth -- more than any other language I am aware of -- would benefit from a "tree" structured editor/browser using stackable windows, where definitions of variables and code are only a keystroke away. I haven't yet seen "Fifth" so I don't know how closely their editor/browser correspond to what I have in mind. I agree with you that "screens suck"--I'm not proposing traditional screens. In fact, I agree that a sequential file is is the way to go. But you can have a normal DOS/Unix file store the Forth definitions without giving up a "hypertext-like" accessing method; I'm just advocating that you turn over the process of definition lookup to the computer. If you want to scroll sequentially through the file, that is okay--but you shouldn't have to. You've mentioned that you just rely on "tags" under Unix. Something like that would work, as long as it was fast enough and allowed the definitions to be displayed in separate windows and allowed windows to be stacked and allowed the window stack to be manipulated in the same way that the numeric stack is currently manipulated. I've used "ctags" with vi on small C code modules and that is kind of nice...but once you chain to a different module you can't "pop" your way back. Perhaps emacs with ctags would allow you to do that, I don't know. For several years I've been hearing rumors that Borland and Microsoft are working on "tree" or "network" editors for use in their language products. In the Nov. 89 issue of Computer_Language (page 111) (in an ad for a C editor similar to what I am proposing for Forth), there is a quote from Phillpe Kahn, himself: "Given a procedure's identifier, an editor should be able to bring up the full procedure interface, including parameters, so that you don't have to remember how many and in what order. Wouldn't it be nice to hit a hot key on the name of a complicated data type and have its definition pop up in a window? It may seem like a real small matter, but how many of you still flip through printouts doing things the editor should be doing?" --Phillipe Kahn, "The Connection", Spring/Summer 1988 One doesn't have to be much of a fortuneteller to predict what tomorrow's Turbo C environment is likely to look like. While C code can be fit into such an editor and, doubtless, benefit from it, Forth code is a much more natural "fit" and would benefit considerably more. o Forth has many more "words" than C and it is effectively a requirement that the programmer understand both the function and the implementation of nearly all words in the Forth dictionary in order to code serious applications. o Forth has no "goto" and is actually more structured than other so-called "structured languages" such as C. Therefore Forth would lend itself more cleanly to a breakdown of a program into a "tree". o Forth's "words" are much more natural than C's functions. They are shorter and more factored. You could probably factor in C to an equivalent extent, but the overhead of functions makes that a bad idea from a practical standpoint. o Forth definitions are generally an order of magnitude shorter than definitions in C. This is a natural outgrowth of factoring. In terms of a tree editor, however, this is a TREMENDOUS advantage since it means that most definitions CAN fit entirely on one CRT screen. Although ability to fit on one CRT screen is not a requirement of such a tree editor (a window can be larger than one screen and be scrollable), from a practical standpoint windows are a much more powerful and acceptable presentation medium if their contents can be views as a "whole". Especially if the idea of shadow screens is used, at least 95% of Forth definitions can fit on one window--even with a "pretty" layout. By the way, I REALLY think the idea of keeping the bulk of documentation in separate, differently sized, "shadows" so it doesn't clutter code is a tremendous advance. The key is to tie the shadow to the word in a more flexible way so that you could potentially have a small definition supported by a HUGE amount of documentation in a scrollable window. ... I know you've already read some of my reasoning in previous postings. It's likely that neither my ideas nor my arguments are terrifically original. But that alone doesn't make them wrong. Unless you've actually used a Forth which has an editor/browser as I've described you shouldn't be too quick to discount it as a much superior interface to Forth. I've argued that a more standardized approach to things such as strings, windows, etc, is very important for the acceptance of Forth -- but [I think we're going to find that] "hyper" editing and browsing is crucial. ----- {pacbell!sactoh0! OR ucdavis!csusac!}tree!stever -- {pacbell!sactoh0! OR ucdavis!csusac!}tree!stever