Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!ENG.SUN.COM!Mitch.Bradley
From: Mitch.Bradley@ENG.SUN.COM
Newsgroups: comp.lang.forth
Subject: ANS TC Magnet for Mass Storage
Message-ID: <9105291721.AA13517@ucbvax.Berkeley.EDU>
Date: 28 May 91 18:11:01 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: Mitch.Bradley%ENG.SUN.COM@SCFVM.GSFC.NASA.GOV
Distribution: world
Organization: The Internet
Lines: 85


 mb> A standard ANS Forth system is not required to reject
 mb> non-printable characters in blocks, nor is it required to accept
 mb> them.  The characters whose meanings are precisely defined in the
 mb> context of block source code are the space character and the ASCII
 mb> characters with codes from 33 to 126.

 rb> Forth-83 allows word names defined on blocks to contain any character
 rb> other than a space.  In Forth-83 there are no restrictions on the data
 rb> that can be stored in a block, a block is simply a 1K segment of RAM
 rb> that interchangeably resides in some form of mass storage.  This "mass
 rb> storage" may itself be as little and as transient as 32K of RAM.

Note that ANS Forth does not restrict the *data* that be stored in a block;
it simply says that the *source code* for a Standard Program should only
contain printable characters and blanks.  Regardless of what Forth-83 says,
there is a fair amount of variation in what real systems do when the
interpreter encounters control characters.

Another way of putting this is:

        If you want your program to be really portable, you better figure
        out how to write the source code with printable characters.

From a pragmatic standpoint, this is a good idea for several reasons,
including the ability to print and publish your code, both in paper form
and over the network.  Essentially, this is equivalent to saying that
a Standard Program can be published with real-world human-readable media.

> The implementation requirements for the Forth-83 Standard word KEY are
> an entitlement to the "Standard Programmer", i.e., a user of a
> FORTH-83 Standard System.  Historically this definition arose because
> of conflicting program needs involving KEY .  Sometimes the program
> needs all of the data coming through the I/O stream, principally here
> meaning through an RS232 serial port.

Increasingly, KEY is being used not only for data coming in over a serial
port, but also for event codes from extended keyboards and window systems,
and also for international characters.  For those other uses, high order bits
do not necessarily represent "uninteresting information" (uninteristing in
the sense that the presence or absense of a parity bit does not change the
meaning of the rest of the bits).  I would claim that having to deal with
visible parity bits at the Forth program level is extremely rare these days,
especially compared to the other cases (extended keyboards, international
character sets, event codes).

> Mitch, I don't understand your readiness to discard the heritage with KEY
> and BLOCK .  My sense of your view toward blocks is, "someone's not-so-
> bright idea of a way to handle source code."

The issue doesn't revolve around BLOCK, but rather around whether Standard
source code can contain "invisible" characters.  I don't think it's a good
idea to allow arbitrary control characters in standard source code.  Standard
implies publication or transmission or multi-platform use or at least long-
term maintainability, and all my experience with the real world tells me
that embedding arbitrary control codes in source code is contrary to all
those goals.

> I know that you've cited control-S and control-Q as implementation
> problems with KEY .  [compliment deleted] I find it difficult to
> understand that you couldn't support the KEY in a program written to
> use DC1 or DC3, Device Control 1 and 3, ASCII values hex 11 and 13.

The problem is that many communications channels intercept or alter
numerous control codes, in ways that are difficult to detect.  The
only reasonable alternative is to define some standard "escape sequence"
for entering otherwise-unreachable codes, similar to C's "\" convention.
This would be a nice feature to have, but I sort of doubt that the
committee would go for it, and I'm not willing to carry the banner on
this one.  If you propose it, I will support it.

> Re: disentitling BLOCK .  The nominal
> rationale that embedded systems don't necessarily need source code doesn't
> wash.  The existence of embedded systems that don't allow source code
> doesn't in any way change the existence of programs that _are_ source code.

Presumably, embedded systems that do not allow source code will succeed
or fail based on the market acceptance of their overall value.  There are
some people (I am not one of them) who are adamantely opposed to even
saying that if you have files, then you must have blocks too.  For a good
argument, call Jack Brown.  This battle have been fought at least 3 times,
and I doubt that anybody's mind is going to change at this stage.


Mitch.Bradley@Eng.Sun.COM