Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!ENG.SUN.COM!Mitch.Bradley
From: Mitch.Bradley@ENG.SUN.COM (Mitch Bradley)
Newsgroups: comp.lang.forth
Subject: Re: ANS TC Magnet for Mass Storage
Message-ID: <9106020331.AA27304@ucbvax.Berkeley.EDU>
Date: 1 Jun 91 05:31:05 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: Mitch Bradley <Mitch.Bradley%ENG.SUN.COM@SCFVM.GSFC.NASA.GOV>
Distribution: world
Organization: The Internet
Lines: 104

> >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.

> Then don't enter them in source code.  But don't limit the functionality of
> the system's tools to handle such data.  KEY and BLOCK (ugh) are used for
> many thing other than funneling data to the interpreter/compiler.

Oops, misunderstanding time!  ANS Forth does NOT prohibit the use of control
characters in BLOCKs.  It says that the use of control characters in *block
source code* is ambiguous.  In other words, some systems may treat them
as word delimiters, and other systems may treat them as characters of a word.
The BLOCK mechanism still has to deliver the control characters without
modification, but the *interpreter/compiler* is not constrained on how it
must deal with them when they are delivered from a BLOCK.

This is a statement of historical reality.

However, in *text file source code*, ANS Forth specifies that control
characters are word delimiters, i.e. "white space".

Implementors have 3 reasonable options:

1) They can make both BLOCK source and text file source work the same way,
   i.e. control characters are "white space".  One might expect that an
   implementor of a new system might do it this way.

2) They can make BLOCK source treat control characters as "non-white" and
   text file source treat them as "white".  This would be a reasonable
   choice for a vendor with a substantial existing customer base devoted
   to BLOCK source code, in which control characters are "non-white".

3) They can refuse to implement text file source code, and do whatever they
   used to do with block source.  My personal prediction is that such vendors
   will get creamed in the marketplace (even FORTH, Inc. now offers text
   file source, due to popular demand), but the market will make the final
   call on that one.

Note that a vendor is not allowed to have the file access wordset without
the BLOCK wordset.  This is an issue that was a matter of much debate, and
the final decision was a compromise.  Note, however, that vendors who really
don't want to support BLOCK can either

a) Supply a "barely adequate" implementation of the BLOCK wordset in source
   form, telling users how to load it if they want it.  (This is what I
   currently do on my Atari Forthmacs system; the one person who has ever
   complained changed his mind a few weeks later, and decided he really
   does prefer text files.)

b) Don't supply BLOCKs at all.  Of course, this means that the vendor is not
   allowed to say he has the file wordset either.  What I would do in that
   case is to say that I have *all the words mentioned in the file wordset*,
   but NOT say that I have "the FILE wordset".  It's a technical quibble,
   but I believe that it's strictly legal.

> A 7-bit KEY is braindamaged!

ANS Forth DOES NOT HAVE a 7-bit KEY.  The person who said that it does was
simply mistaken.

KEY returns characters from the "implementation-defined character set".
If the implementation says it has an 8-bit character set, that's what
KEY returns.

However, a Standard Program without environmental dependencies cannot
*assume* that it can get any particular character outside the range of
printable 7-bit ASCII characters.  This does not mean that implementations
are supposed to throw away characters outside that range.  It means that
implementations are not required to simulate 8-bit characters on systems
that don't have them, consequently a completely-portable program better not
depend on them.

A program *can* simply declare an environmental dependency on a particular
character set if it needs it.   Such a program would be labeled as:

        ANS Forth Standard Program with environmental dependency on
        8-bit ISO xxx character set.

Here is an example:

        This code fragment has no environmental dependency; it only tests
        for particular characters in the 7-bit printable "common subset":

                BEGIN
                   KEY DUP  [CHAR] q  <>
                WHILE
                   PTR @ C!  PTR @ CHAR+ PTR !
                REPEAT

        Note that the preceding fragment does not prohibit the use of
        8-bit characters; but it also does not depend on them.

        We could give this code an environmental dependency by replacing
        "[CHAR] q" with "305", thus assuming that it is possible to receive
        the character whose numeric code is "305", which is outside the
        "guaranteed range".  Clearly, on a machine which only has US ASCII
        characters, this loop will never terminate.

An environmental dependency is not a "mark of shame".  It is simply a
statement about what kind of environment the program is intended for.
There are about a zillion programs in the world that have an "environmental
dependency on DOS", and that doesn't seem to be hurting most of them.

Mitch