Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!MITCH.ENG.SUN.COM!wmb
From: wmb@MITCH.ENG.SUN.COM
Newsgroups: comp.lang.forth
Subject: Re:  ANS FORTH TECHNICAL COMMITTEE
Message-ID: <9004101442.AA06210@jade.berkeley.edu>
Date: 9 Apr 90 17:48:28 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: wmb@MITCH.ENG.SUN.COM
Organization: The Internet
Lines: 78

> Losses to the standard program include:
> ...
>     KEY   This one just changed as of BASIS11.  32 out of 128
>           characters gone.  Note that programs cannot get a
>           carriage return using KEY .  (Some UNIX's usurp ^S and
>           ^Q.  With the Forth-83 spec, implementor's provide
>           programs some way for these characters to get from the
>           keyboard to the program, such as reserving function keys,
>           or specifying combinations of keystrokes that are
>           interpreted as one input to KEY .)

Here is my 2 cent's worth on this issue:

a) The definition of KEY in BASIS11 is broken.

b) The reason is because there are 2 conflicting requirements, and
   people seem to think that the single word KEY must simultaneously
   fulfill both requirements.

The 2 requirements:

1) "hardware key": returns a number indicating exactly which key (or keys,
   in the case of "chords", like shift, control, etc) that the user typed.

2) "ASCII key": returns a number from the set 0...127, representing a
   7-bit ISO character.

You can't have both (1) and (2) and call them the same word.

Many peaple argue with great fervor that (1) is what they want, but (1)
is not, and cannot possibly be made to be, portable.  On the other hand,
it can be used quite profitably in a section of code that is environmentally
dependent (e.g. in a "DOS version" of an otherwise portable program).

(2) is necessary for a program that intends to concern itself only with
"standard characters".  (Note that this self-imposed restriction can be
valuable; those standard characters can be stored in files and transmitted
across many communication channels.  The further restriction of only
using printable characters can also be valuable; note that we all pretty
much adopt this further restriction in postings to these networks).

Okay, you say, but why not make (1) the primitive and then synthesize (2)
by masking off the high bits?

Well, because it won't work.  How does the program know whether those
high bits are something boring like parity, or instead a code that
tells you that the character is not an ASCII character at all, but
instead a function key or a mouse event or something.  (hex) C1 might
be 'A' with parity, or it might be the "Home" key.


Here is the most general solution, requiring 2 words (quibble about
the names all you want; it's the semantics I'm interested in:

KEYBOARD-EVENT  ( -- n )
   Returns a number specifying the next keyboard event.  The encoding
   of the event is implementation-defined.  All keyboard events that
   the Forth implementation is able to receive from its environment
   must be available through KEYBOARD-EVENT .

EVENT>CHAR  ( n -- false  |  char true )
   If the event "n", as if returned by KEYBOARD-EVENT, represents a
   character in the ISO character set, returns true and that character.
   Otherwise returns false.

Then, you code define the portable "KEY" as

   : key   begin  keyboard-event event>char  until  ;

Why not just have 2 functions KEY and EVENT ?  You have to specify what
happens if the program is expecting an ASCII characters (with KEY) and
instead the user types a function key, for instance.  Does the function
key get ignored?  Thrown away?  Stuck on a different queue for later
transmission out-of-sequence?  It is important to have a single function
to receive an ordered sequence of primitive events, and an orderly
way of interpreting those events.

Mitch