Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!touch!mikeh
From: mikeh@touch.touch.com (Mike Haas)
Newsgroups: comp.lang.forth
Subject: Re: Control characters
Keywords: n
Message-ID: <229@touch.touch.com>
Date: 5 Jun 91 23:00:42 GMT
References: <9105291726.AA13700@ucbvax.Berkeley.EDU> <1991May30.002016.22178@csi.uottawa.ca>
Organization: Touch Communications
Lines: 25

In article <1991May30.002016.22178@csi.uottawa.ca> cbbrowne@csi.uottawa.ca (Christopher Browne (055908)) writes:
>
>Anyway, the KEY/EKEY compromise seems MOSTLY ok.  I worry about the
>dependencies tho - most parts of a "Standard" system will use KEY for
>input, which means that it may be difficult to use standard/core words
>to do input of odd characters.  I thinking that it may be a neat
>idea to use vectored execution, and perhaps swap between use of KEY and
>EKEY within applications.  Or maybe that makes life even more complicated.

Vectored execution IS the way to go.  However, in such a system, you would not 
"swap between the us3e of KEY & EKEY"...you would always use KEY, just put
EKEY (or whatever KEY-primitive) in the vector.  In fact, you have to be
in such systems to never place a primitive which, in turn, calls KEY into
the KEY vector.  That's generates a recursive overrun...
overrun...
overrun...
overrun...
<AAACH!>...eat into data stack...
overrun...
overrun...
<AARGH!>...eat into dictionary...
over..
o...
... ... ... <die>