Stephen Pelc wrote:
>
> > Problem
> >
> > How do I write a portable Forth program that reacts to key presses of
> > cursor keys (and possibly other keys not represented by ASCII), e.g., an
> > editor?
>
> I think of applications in three basic groups:
> embedded
> mobile/PDA
> desktop
>
> This proposal is firmly in the desktop arena.

Yes. It's certainly not useful for programs that run on computers
without keyboards.

> IMHO it introduces
> unspecified linkages between KEY, KEY? and ACCEPT and EKEY,
> EKEY? and EKEY>CHAR. These linkages need to be explicit
> (defined).

No such linkages are intended. Why do you think that this proposal
introduces such linkages?

> Note that the original definition of EKEY talks about
> "keyboard events".

And?

> I suspect that the proposal is feasible because most desktops
> use the same keyboard mechanisms - common hardware chips?

This proposal is intended to be independent of specific hardware
chips, and of whatever mechanisms there may be between the keyboard
and the Forth program. The only mechamisms that are required for this
proposal to be useful are that there is a keyboard with at least some
of these keys attached to the system, and that the fact that the user
presses such a key is reported to the Forth system.

As an example, I have just started gforth on a computer called b3 (a
PC running Linux). I ran the following line:

ekey k-left = .

and then, when EKEY waited for input, I pressed the cursor left key.
The output of this line was:

-1 ok

I typed the key on my home machine (about 2km from the b3), and the
mechanisms involved were the keyboard, the Linux kernel, the X window
system, the xterm program, the ssh (all on my machine), some
networking stuff, the sshd (on b3), and gforth. And the key event was
translated from whatever code the keyboard uses internally to an X key
symbol (by X; maybe the Linux kernel does another translation
earlier), to an ESC sequence (by xterm), and the finally to the value
returned by K-LEFT (by Gforth). I think that demonstrates that the
proposal is not tied to specific hardware chips.

> I believe that this proposal needs more work in two areas:
> 1) domain specificity

What kind of work do you have in mind?

> 2) the assumptions and linkages with EKEY.

The only linkage intended by the proposal is that EKEY may return the
values returned by the proposed words. What assumptions and linkages
do you have in mind.

> The danger in the EKEY assumptions lies in inadvertently
> disenfranchising embedded apps.

I don't know how such a disenfranchisement is supposed to happen.
This is an optional extension, so there is no requirement for a system
to support it (although it's a good idea to do it where appropriate).

And there is certainly no requirement for an application to use it.
If an application does not use these words, it will still compile and
run.

This is just like floating-point or files. Not all systems support
these capabilities, but for those that do there is a common word set.

- anton