Path: utzoo!utgpu!watserv1!watmath!att!pacbell!pacbell.com!decwrl!wuarchive!udel!rochester!pt.cs.cmu.edu!dsl.pitt.edu!pitt!willett!ForthNet
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: ANS FORTH TECHNICAL COMMITTEE
Message-ID: <1686.UUL1.3#5129@willett.pgh.pa.us>
Date: 7 Sep 90 02:09:02 GMT
Organization: String, Scotch tape, and Paperclips.  (in Pgh, PA)
Lines: 73

Category 18,  Topic 16
Message 36        Thu Sep 06, 1990
D.RUFFER [Dennis]            at 01:19 EDT
 
Re: ir230@sdcc6.ucsd.edu (john wavrik)

 > "You used to create control structures, in-line data handlers,
 > etc. by storing addresses in the dictionary, using your access to
 > the IP, etc. -- now, under the proposed ANSI Standard, you will
 > be able to accomplish the same things in the following way:

Use POSTPONE in place of  ' ,  COMPILE  [COMPILE]  In most cases, that is all
you will ever need.  If you know of a specific case where this will not solve
the problem then you may need to look at the problem in a different light. 
This may mean re-writing sections of your code.  However, the goal of the ANS
Forth Standard is to enable you to *WRITE* portable code, not to make non-
portable code magicly become portable.

 >> To do more would prevent those systems from
 >> complying with the standard.

 > I think this is an example of the kind of thinking that is
 > crippling the standardization effort.

I am very sorry that you think Chuck Moore, Harris Semiconductor, etc. have
"crippled" Forth, but that's life.  If the biggest supporter of Forth in
hardware and the designer of Forth decide that stack addressing is not
necessary, then I guess someone might want to listen.  The people who listened
have changed Forth, and the ANS TC *must* listen and write a standard that
allows them to participate.  Otherwise, what do we have, two standards? 
Three?

 >  Do we say that because a special class of machines is not suited
 >  for recursion, Forth in general will not be suited for recursion.

 > The ANS-Forth approach to language standardization is to choose
 > the second alternative.

This is hogwash John.  Of course Forth can do recursion.  Even before RECURSE
(and all its variants) Forth programmers knew how to do it and the ANS TC
recognizes it by including the word in the CORE wordset.  However, good
programming practices dictate that the programmers knows what resources his
program uses and checks that those rsources are available before attempting to
use them.

Let me ask you John, if you buy a software package for a PC that says that it
requires 512K of memory to operate, do you get pissed because it does not
operate on your 256K machine?  Maybe, but if you really want to run that
package, your only recourse is to go out and buy more memory.  What the ANS TC
has given us is the same capability that exists for PC memory.  The program
can inquire about how much stack space is available, and it it is not enough,
it can abort with an appropriate error message.  On your system, you as a user
can easily solve the problem (as you have shown), and IMHO most Forths will
have a similar capability.  It is even likely that providers of CPU Forth
systems will also provide their users with some capability to increase the
stack, possibly with performance penalties.  However, let's not muck up the
standard with something that would hamper how the vendors might accomplish it.

Are you also pissed that you can't run my 320K portable application in your
64K system?

 > [We must ask whether we are in danger of eliminating from Forth
 > precisely those qualities which would lead someone to pick it in
 > preference to other languages.]

Do you have doubts that the vendors who are on the TC have asked this question
and continue to ask it every time someone wants to add something that they can
not support?

That IS the whole point.   DaR
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us