On 5 Jun 2006 at 15:04, Bernd Paysan wrote:

> Not really. The PC has a 8042 based keyboard, which is then translated
> to the X keyboard event (which is an abstraction for quite a number of
> different possible keyboards, and developed when Linux PCs where not
> even thought about). It then goes into a xterm, which emulates a VT102
> terminal.

I take your point, but both start from the Linux kernel and
libc. There are other operating systems.

The point at issue is really that the proposal seems to be
derived from writing editors in GUI desktop applications. I
regard this as a library issue, and increasingly would like to
see some separation of language and library. This does not mean
that I want the same separation as in the "C Standard library".
I'm arguing that there are at least three major application
domains, and that we should recognise this. The -EXT labelling
is inadequate for this.

I'm happy to have a floating point standard, which is really a
CPU issue. However EKEY was deliberately invented as a place-
holder for implementation specific behaviour. The implication of
this proposal is to normalise part of EKEY's behaviour. Is this
a good thing? On a desktop there is no real penalty for adding a
synonym, so rename *this* EKEY implementation to GKEY and call
it:
LIB: Desktop key handling for Linux and libc
and some problems go away, otherwise the Forth200x standard is
in danger of being perceived as the gForth extension standard.
Has anyone implemented this EKEY under the Windows API or
Symbian?

A standard should be derived from common practice, maybe from
another language. What common pratice does this proposal have in
Forth *applications* as opposed to *kernels*?

Stephen
--
Stephen Pelc, stephen@...
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads