Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!ucbvax!MITCH.ENG.SUN.COM!wmb
From: wmb@MITCH.ENG.SUN.COM
Newsgroups: comp.lang.forth
Subject: ANS Forth
Message-ID: <9009070010.AA16734@ucbvax.Berkeley.EDU>
Date: 6 Sep 90 17:31:23 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV
Organization: The Internet
Lines: 33

> We've established that most users will need to do considerable
> rewriting to have existing code comply with the proposed ANSI
> Standard.

Have we indeed established this?  We have seen some examples of
code that is not compilant, but we have not established the extent
to which such code exists in the applications of "most users".


> And we've established that tools that they have used in the past will
> not be available -- so it is just a matter of learning about what newer
> and better tools the ANSI team has provided.

Have we indeed established this?  Forth system vendors will continue to
provide at least the same level of tools that they currently provide
(trust the marketplace to ensure this), and users will still be able to
create implementation-dependent tools as they do now.


>     "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:

You used to create (etc. etc.) using your *implementation dependent*
access to the IP, etc.  ANS Forth won't make these techniques portable,
but neither did it create the existing portability problem.

Like it or not, these techniques have never been portable except among
selected subsets of Forth systems.  Even in the halcyon days of FIG Forth,
there were other Forth implementations that did things differently.

Mitch Bradley, wmb@Eng.Sun.COM