Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!BRFAPESP.BITNET!UNBCIC
From: UNBCIC@BRFAPESP.BITNET
Newsgroups: comp.lang.forth
Subject: ANS Forth
Message-ID: <9105291726.AA13694@ucbvax.Berkeley.EDU>
Date: 28 May 91 15:22:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: UNBCIC%BRFAPESP.BITNET@SCFVM.GSFC.NASA.GOV
Distribution: world
Organization: The Internet
Lines: 98

=> Category 10,  Topic 15
=> Message 21        Sat May 25, 1991
=> R.BERKEY [Robert]            at 20:45 PDT
=>
=>
=>  To: Mitch Bradley
=>
=>  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.
=>
=> Forth-83 allows word names defined on blocks to contain any character other
=> than a space.  In Forth-83 there are no restrictions on the data that can be
=> stored in a block, a block is simply a 1K segment of RAM that interchangeably
=> resides in some form of mass storage.  This "mass storage" may itself be as
=> little and as transient as 32K of RAM.

We were talking about SOURCE code in blocks. Specifically, if CHAR should
accept an >127 character.

=>  mb> "127 AND" is often used after KEY to remove junk like parity bits
=>  mb> and shift bits.  This technique, although quite common, is bogus,
=>  mb> because throwing away high bits doesn't necessarily result in a
=>  mb> meaningful 7-bit ASCII character.  Instead it may for example
=>  mb> transform a code that means the "F7" function key into the letter
=>  mb> "T", a behavior for which I can think of no justification.
=>
=> 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
   .
=> It's a serious handicap to professional engineers when the implementation
=> arbitrarily discards data from the physical level of the I/O stream.  At the
=> logical level of use, just what that data means may simply be information
=> relevant to the I/O stream, such as a parity bit, and not interesting in the
=> logical interpretation of the data.  The point of the system requirements
=> involving the Forth-83 Standard word KEY is to assure that the application
=> level on a system-specific basis is able to make relevant decisions regarding
=> how to interpret physical-level data.  Further, the Forth-83 Standard
=> guarantees a Standard Program access to logical data, i.e., that all 128 ASCI
   I
=> characters can be received.  The Forth-83 Standard further specifies the ASCI
   I
=> standard as a normative appendix.

If you want binary data input, you can use EKEY. It's provided for that.

=>  mb> The correct phrase should be something like this:
=>
=>  mb> 126 constant max-graphic    \ Value depends on system character set
=>
=>  mb>    ...
=>  mb>     key  dup bl max-graphic  between  if   ( char )
=>  mb>        <insert character in buffer>
=>  mb>     else
=>  mb>        <process as editing character>
=>  mb>     then
=>
=> That happens to be an example of a program using the Forth-83 KEY .
=>
=> 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 ide
   a
=> of a way to handle source code."  I know that you've cited control-S and
=> control-Q as implementation problems with KEY .  Yet especially knowing your
=> prodigious ability as an implementor, 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.  (If this issue is a "quibble",
=> then are excuses for not providing a full implementation of KEY other than
=> "quibbles"?)

There is a full implementation of KEY. It's name is EKEY.

=> By the way, I consider X3.J14's handling of the definitions of KEY and BLOCK
=> two of the bigger objections going, either being plenty of reason for
=> reasonable people to reject the label "ANS Forth Standard".  The deletion of
=> EXPECT could be rationalized if KEY were conventionally functional.  KEY can'
   t
=> input a <RETURN>?  In my opinion, the committee decision here lacks serious

Key accepts anything with 7 bits.

=> commitment to standardization.  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.

Again, we were discussing the behavior of blocks when used as SOURCE code.

=> Robert

                              (8-DCS)
Daniel C. Sobral
UNBCIC@BRFAPESP.BITNET