Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!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: Input/Output Message-ID: <2851.UUL1.3#5129@willett.pgh.pa.us> Date: 4 Jun 91 02:41:07 GMT Organization: (n.) to be organized. But that's not important right now. Lines: 65 Category 10, Topic 23 Message 1 Sun Jun 02, 1991 R.BERKEY [Robert] at 22:19 PDT Daniel C. Sobral writes, 28 May 91, > => Category 10, Topic 15 > => Message 21 Sat May 25, 1991 > => R.BERKEY [Robert] at 20:45 PDT ... > => KEY can't input a ? In my opinion, the committee > => decision here lacks serious commitment to standardization. > Key accepts anything with 7 bits. I don't agree. The new limitation is in Appendix C, and applies to EKEY as well as KEY: Only the range hex 20-7E is pertinent to this standard, and the semantics of character values outside this range is implementation-defined. Use of the graphic hex 24 (the currency sign) is an environmental dependency. A "Normative Annex", in case that isn't clear, means that the text is part of the Standard, as opposed to being supplementary material. This thing about characters can get confusing real quick. In Forth-83, a "character" was the set of 128 ASCII characters, including both control and graphic characters. In BASIS, a "character" as used for I/O is the set of 95 ASCII graphic characters, {20-7E}, and if the character is visible, i.e., in source code or being displayed with TYPE or EMIT, the currency graphic, '$', or hex 24, cannot be used. A "char" is decimal {32-127}. This value limits inputs to C! FILL and C, among others. By the way, "char" as defined in BASIS15 was changed from {0- 127} to {32-127} _during_ the dpANS vote, which shouldn't have happened. Also, I think it is routine to see 0
C! in Forth. Another common practice which had already been disallowed is:
C! In BASIS, a "character" is also a unit of data storage known to be at least 8 bits, although there is no way to store 8-bit data in a "character". These X3.J14 proposals for KEY C! and FILL are the most severe form of change for a language committee, when conversion of previously conforming code is not possible and the syntax is left unchanged. 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