ma168a@sdcc3.ucsd.EDU (John Wavrik) (11/26/86)
Most of my work with Forth (for 8 years) has been in mathematics research. I
have also used (MMS) Forth packages to meet my word-processing and database
needs. As a result, I have rarely been mindful of the fact that Forth is
isolated from the DOS environment. My only notice, in fact, was that
information from programs -- or even program source -- needed to be sent to
other computers from within the Forth environment.
Recently I was faced with the problem of writing a filter program to convert
text files to PostScript files suitable for an Apple LaserWriter. Forth would
have been ideal for providing a modifiable filter. Unfortunately, the
production of a free-standing program that operates on DOS files does not seem
compatible with the way Forth is implemented. The best I could do using
MMS-Forth (which, at least, provides a conversion utility) is to convert the
source file to a Forth file, process the Forth file, and convert the result
back to DOS format. I wound up developing the core program in Forth and
recoding it in Pascal!
It not my job to implement languages. I realize that it is easiest to
implement a compact, self-contained programming environment. I cannot assess
what is involved in extending the environment. I can only report, as an avid
Forth user, the frustration of knowing how do do something useful in the
"outside world" but feeling boxed in by a system that does not provide outside
access.
The committees that guide this language are involved with such issues as
whether conditionals should leave -1 or 1 on the stack; and whether LEAVE
should exit immediately or be more patient. I wonder if there has been any
work concerning the interaction of Forth with "foreign" operating systems.
J. Wavrik
UCSDtoma@tekgvs.UUCP (Thomas Almy) (11/27/86)
In article <3674@sdcc3.ucsd.EDU> ma168a@sdcc3.ucsd.EDU (John Wavrik) writes: > > Most of my work with Forth (for 8 years) has been in mathematics research. > I have also used (MMS) Forth packages to meet my word-processing and > database needs. >... > It not my job to implement languages. I realize that it is easiest to > implement a compact, self-contained programming environment. I cannot assess > what is involved in extending the environment. I can only report, as an avid > Forth user, the frustration of knowing how do do something useful in the > "outside world" but feeling boxed in by a system that does not provide > outside access. > ... > I wonder if there has been any work concerning the interaction of Forth > with "foreign" operating systems. There are many Forths that run under "foreign" operating systems. I started with MMS Forth for the TRS-80. While MMS-Forth is a fine system, I too was agravated by lack of DOS access. Besides missing file access, I could not access new storage devices without having to write my own drivers! I ended up implementing my own Forth for the TRS-80 (which I readily ported to CPM at a later time). Having gotten used to such an environment, since there are no generic Forths for Z-80 systems except those which run under CP/M, I have avoided them ever since. For instance I have a copy of PolyForth for the IBM/PC that is such a good test of PC compatibility that it refuses to run on every clone I have tried! Currently I use Laboratory Microsystem's UR/Forth (note -- I do have some financial connection to LMI since they sell my NCC and CFORTH products, but no financial connection concerning UR/Forth). This is a "well behaved" program that allows full I/O redirection and supports the MS-DOS file and device interface. You can even execute other programs from within Forth with the SHELL command. Unlike other implementations, this one was generated by "compiling" each word into an object module, and then linking all the modules with the MS-DOS linker. It is possible to link to subroutine packages in other languages for such things as math/stat packages, graphics/windowing, or whatever suits your needs. You can also make use of resident utilities (Sidekick, keyboard enhancers, spoolers...) and can run the program under a windowing environment. In fact, they evey have a Xenix version. This Forth, and most Forths that run in a DOS environment, allow loading code from text files. Screen files are still supported for die-hards (including me, by the way), although the combination of Sidekick and Forth is very handy. Even with my fond memories of MMS Forth (I originally wrote my CAD system in it), I would never go back. Tom Almy
tenney@well.UUCP (Glenn S. Tenney) (11/28/86)
In article <3674@sdcc3.ucsd.EDU> ma168a@sdcc3.ucsd.EDU (John Wavrik) writes: >... > The committees that guide this language are involved with such issues as > whether conditionals should leave -1 or 1 on the stack; and whether LEAVE > should exit immediately or be more patient. I wonder if there has been any > work concerning the interaction of Forth with "foreign" operating systems. Your complaint of inadequate (nonexistant?) support with DOS files for a commercial FORTH system should be with the vendor, NOT with any "standard". I believe that *ANY* commercial FORTH system should implement an interface with its host OS including a way to do file I/O. There is MUCH work showing interaction with host OSs such as F-83 or MVP-FORTH (Amiga and I believe other versions). -- Glenn Tenney UUCP: {hplabs,glacier,lll-crg,ihnp4!ptsfa}!well!tenney ARPA: well!tenney@LLL-CRG.ARPA Delphi and MCI Mail: TENNEY As Alphonso Bodoya would say... (tnx boulton) Disclaimers? DISCLAIMERS!? I don' gotta show you no stinking DISCLAIMERS!
ma168a@sdcc3.ucsd.EDU (John Wavrik) (12/02/86)
< Glen Tenney writes: >Your complaint of inadequate (nonexistant?) support with DOS files for a >commercial FORTH system should be with the vendor, NOT with any "standard". >I believe that *ANY* commercial FORTH system should implement an interface >with its host OS including a way to do file I/O. One question is WHAT host operating system? Both historically and in common practice, Forth is a combination language and operating system. When Forth developed, one of its major assets was that it would allow substantial amounts of computation to be performed in 16k or less. It performs this miracle by containing its own operating system and interpreter/compiler. In most versions of Forth no other operating system is in residence: Forth owns the disk (or its own hard disk partition). At work I use Kitt Peak VAX-Forth. It provides an "escape" word that allows (certain) operating system calls to be issued from within Forth. It allows the creation of Forth block files which are logged in to the operating system directory. The Forth environment is still like a box, but here it is a box with a window. Kitt Peak provides utilities for converting Forth ASCII files to and from operating system text files -- it is significant that these utilities are written in 'C'! The problem of manipulating DOS files using Forth is only one symptom of Forth encapsulation. The fact that an expert Forth programmer might be able, for a particular implementation of Forth on a particular computer, to write enough of an operating system to read and alter DOS directory, file allocation tables, etc. is irrelevant. The original posting on DOS access was illustrated by an example: the problem of manipulating DOS files from within the Forth environment. The real question, however, was about breaking the mold in which Forth is cast: "a self-contained environment mainly for use on small machines". Forth, in the past, was a language for the creation of applications for a single computer and specific hardware. It now has a community of users whose applications go far beyond this. Some vendors have produced versions of Forth that use DOS text files rather than blocks, subroutine calls rather than lists of addresses, etc. Major alterations of this sort in the implementation of the language should not be required just to allow it to extend its environment. It is desirable, nevertheless, that experimentation occur: a standards team should always select words that have actually been implemented and used. One of the greatest assets of Forth among high level languages has been its high degree of portability. Applications could (until the '83 standards) be developed on one computer and run on another using a different Forth system with no change in Forth code (but, perhaps, after loading an adaptation module containing a block or two of redefinitions). Those concerned with portability must write applications in terms of "standard" words using "standard" programming practices. The power of Forth in this context is limited by what the standards teams provide. The bottom line is that if Forth is to be unencapsulated it must be done in a portable way and in harmony with its history and nature. This is not something to be left for vendors to implement haphazardly as "enhancements". --J Wavrik Math Dept UCSD ucbvax!sdcsvax!sdcc3!ma168a sdcc3%ma168a@SDCSVAX.UCSD.EDU
dickow@ui3.UUCP (12/09/86)
:
I have used Forth for a few years, and never found it too "foreign"
when reading non-forth environment files. However, the Forth I have been
used to (Parsec Research's SuperForth64) has built in extensions that allow
reading and writing "ordinary" DOS formats. True, processing the data is
easiest using Block related words. Reading sequential data into a "temp-
orary" block, perhaps, although streaming shouldn't be too difficult either.
Forth should be ideal for setting up these kinds of processing.
Incidentally, some systems even set up standard non-forth-block oriented
editors. This means you can edit with your word processor in a continuous
fassion, then compile later. Obviously this demonstrates Forth working with
non-system environments. The forth I am refering to is JForth, if youre
curious. It is out now for the Amiga. (See next basenote). JForth also
supports the usual block file structure.
---Bob Dickow
---University of Idaho
egg-id!ui3!dickowwmb@sun.uucp (Mitch Bradley) (12/14/86)
For several years now, at every Forth conference I have attended, I have been pushing for a portable set of operating system file access words. The first proposal was at the 1983 FORML conference, where I presented a description of and source code for a file system interface very similar in principle to C's "stdio" package. If anybody is interested, I would be happy to send you a copy of the paper. Design goals: 1) Forth should use the operating system's native file structure, so that Forth may be used in cooperation with other system utilities. 2) The Forth words used to access files should be the same regardless of which operating system Forth is running under. So far, the system has turned out to be pretty portable; it is running under Sun's, CP/M F83, CP/M MVP-Forth, Forthmacs on the Atari ST, and Forthmacs on the Macintosh. Some porting effort is necessary, but the "gotcha's" have largely been eliminated. For suggestions about interfacing to operation system functions other than files, look through my previous posting about interfacing Forth and Unix. The same techniques have proven useful on systems other than Unix (e.g. Atari TOS and the Macintosh Toolbox). Mitch Bradley