Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!ucbvax!BRFAPESP.BITNET!UNBCIC
From: UNBCIC@BRFAPESP.BITNET
Newsgroups: comp.lang.forth
Subject: ANS Forth
Message-ID: <9106020331.AA27313@ucbvax.Berkeley.EDU>
Date: 1 Jun 91 17:54:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: UNBCIC%BRFAPESP.BITNET@SCFVM.GSFC.NASA.GOV
Distribution: world
Organization: The Internet
Lines: 53

=> >The issue doesn't revolve around BLOCK, but rather around whether Standard
=> >source code can contain "invisible" characters.  I don't think it's a good
=> >idea to allow arbitrary control characters in standard source code.  Standar
   d
=>
=> Then don't enter them in source code.  But don't limit the functionality of
=> the system's tools to handle such data.  KEY and BLOCK (ugh) are used for
=> many thing other than funneling data to the interpreter/compiler.  In fact,
=> when most forth "applications" are running, doing what they were designed
=> to do, the often use KEY and BLOCK (no?) and never invoke the interpreter.

Ok, so you AGREE with the decision made by X3J14. You can't enter invisible
characters in a Standard program, but you can use BLOCKs for whatever you want
(THERE IS *NO* LIMIT TO WHAT YOU CAN PUT IN BLOCKS!!!). You want >7 bits input?
Then use EKEY. KEY is still there, but for 7-bits input. Maybe the TC throw out
EKEY and make KEY acts like EKEY (puts a word in the stack with the input).
That would be useful for me (I use 8 bit characters).

=> Other languages have been adding page formatting control characters
=> since day 1...right in with their source code.  any forth system worth
=> it's salt should be able to handle TAB characters as generic whitespace,
=> like BL.  Why the hell not?  I HATE it when someone designs limitations
=> into the development tools i have to use...especially forth tools, where
=> I can type in R> at the keyboard!  This is an advantage, this power.  Why
=> take it away?  Remember, as a forth developer, you're creating MY tools;
=> you can't possibly know what I'm going to want to do with them, especially
=> with a language like forth!

That's what was happening. ZEN 15a treats anything greater than 126 and lower
than 33 as a generic whitespace. So I asked Mitch if that was OK with BASIS 15,
and he answered that ANS Forth let the compiler do anything with caracters not
within 32 and 126.

=> Then there are platforms (like tha amiga) where you can type in ANSI
=> escape codes to do VT-100-like forms management (including changing
=> text & background color).  a 7-bit KEY is braindamaged!  Quit trying
=> to protect me from the power of forth.  Both the mac & amiga use the
=> full 8 bits for data...don't strip this out just cause your forth
=> interpreter can't handle it.  forth needs to ADAPT to these systems...
=> even 8-bit text is old stuff, the world is now trying to figure out
=> international language support (16 bits & MORE!)...THIS IS WHAT WE
=> SHOULD BE FIGURING OUT!...
=> not whether KEY is gonna pass 8 bits!  ludicrous.  ADAPT...
=> it may be in Websters, but it sure isn't in many 'forth' dictionaries!

I consider EKEY an adaptation, don't you? ANS Forth have files also. And Error
Handling. And a powerful dictionary wordset. And floating point. And Double
Numbers. And many other things. Ok, we don't have Windows or Graphics, but no
Standard do (there are just too many "Standard" GUIs). What else do you want?

                              (8-DCS)
Daniel C. Sobral
UNBCIC@BRFAPESP.BITNET