Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pitt!willett!ForthNet From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) Newsgroups: comp.lang.forth Subject: ANS TC Magnet for Mass Storage Message-ID: <2825.UUL1.3#5129@willett.pgh.pa.us> Date: 27 May 91 18:55:44 GMT Organization: (n.) to be organized. But that's not important right now. Lines: 83 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. 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 ASCII characters can be received. The Forth-83 Standard further specifies the ASCII standard as a normative appendix. 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> mb> else mb> 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 idea 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"?) 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 ? In my opinion, the committee decision here lacks serious 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. Robert ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp