Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!rutgers!husc6!panda!genrad!decvax!ucbvax!sdcsvax!sdcc6!sdcc3!ma168a
From: ma168a@sdcc3.ucsd.EDU (John Wavrik)
Newsgroups: comp.lang.forth
Subject: Re: DOS access
Message-ID: <3675@sdcc3.ucsd.EDU>
Date: Tue, 2-Dec-86 12:06:25 EST
Article-I.D.: sdcc3.3675
Posted: Tue Dec  2 12:06:25 1986
Date-Received: Tue, 2-Dec-86 22:41:55 EST
References: <3674@sdcc3.ucsd.EDU> <2132@well.UUCP>
Organization: University of California, San Diego
Lines: 62
Summary: clarification of discussion



 <  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