Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!MJM.XYPLEX.COM!milan From: milan@MJM.XYPLEX.COM (Milan Merhar) Newsgroups: comp.lang.forth Subject: KEY and EKEY Message-ID: <9106020321.AA27095@ucbvax.Berkeley.EDU> Date: 30 May 91 15:54:32 GMT References: <9105300204.AA05191@xyplex.com> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Milan Merhar Distribution: world Organization: The Internet Lines: 38 Mitch Bradley suggested: > My current thinking is that EKEY could be eliminated, and KEY should > be defined to return a *number*, not a character. > There should be a constant (or perhaps an environment query) for > MAX-CHARACTER . If the number returned by KEY is less than MAX-CHARACTER# , > then it is a character in the implementation-defined character set. If the > number is outside that range, it represents an event (function key, whatever) > in an implementation-defined event space. The crucial point is that the > set of valid characters is well-defined subset of the set of events, and > it is possible for a program to test whether or not the thing returned > by KEY is or is not a character. Presumably, a standard program would > discard non-character events, or pass them to a system-specific event > handler routine. I agree completely. I'm sure someone will ask the question, so let's get it over with: "If I'm so careful to write a STANDARD PROGRAM, why can't I expect a STANDARD SYSTEM that doesn't throw those "*@$%??!" implementation- specific input characters at me when I use the standard input word?" My answer, only slightly tongue-in-cheek, is "a conservatively- designed program must be very liberal in the input data it accepts." In other words, the _programmer_ remains responsible for bullet-proofing, NOT the machine. After all, the machine doesn't know if the program is doing data-entry or is pushing a cursor around; all it knows is that sometimes the user types on the keys with letters, and other times on the keys with funny stuff on the tops. I am quite sure that other options to the "KEY" problem exist, including making KEY "state smart" where "state=input_mode", and vectoring KEY to be either "GET-STANDARD-KEY" or "GET-ANY-KEY". As with the battles over "TICK", equally reasonable arguments can be raised about standardizing the "clever" word, or the "stupid" words underlying it. Mitch suggests standardizing the lower-level word, and giving the user the system information needed to build the higher-level word, if they wish to. Why not?