Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!ENG.SUN.COM!Mitch.Bradley
From: Mitch.Bradley@ENG.SUN.COM
Newsgroups: comp.lang.forth
Subject: Re: Memory Management/PIC
Message-ID: <9105021355.AA15317@ucbvax.Berkeley.EDU>
Date: 1 May 91 21:32:16 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: Mitch.Bradley%ENG.SUN.COM@SCFVM.GSFC.NASA.GOV
Organization: The Internet
Lines: 53

> The X3.J14 proposal would break numerous Forth programs ("broken code" is
> that which is compliant with the previous standard, but which is non-
> compliant with the new standard, and thus can no longer be relied upon to
> port between Standard Systems).

My definition of "broken code" is somewhat different.  I am not too
concerned about breaking existing "standard programs".  This may seem
surprising, but here is my reasoning:

        1) There aren't many existing "Forth 83 Standard Programs".
           I have seen a few, but not many.
        2) Of the few I have seen, none has any "economic momentum"
           behind it.  "Economic momentum" is when a company has spent
           a million dollars developing and supporting a program.

The "breaking code" scenario that concerns me more is the following:
        1) Vendor "x" has some number of customers, each with substantial
           investments in their existing applications.
        2) The new standard imposes a requirement that vendor "x" cannot
           meet and still remain compatible with his customers' existing
           code.

The "breaking vendors" scenario would have these effects:
        a) Such vendors would have a disincentive to implement the
           new standard.
        b) A substantial number of vendors probably would not implement it.
        c) The Forth world would become even more fragmented.

A strong goal of ANS Forth is to make it as easy as possible for
existing implementations to migrate to the new standard, thus encouraging
widespread availability.

The focus is on not requiring vendors to break their customers' code, rather
than on ensuring that ANS Forth is a strict upward-compatible superset of
Forth 83.  ANS Forth imposes some usage restrictions that Forth 83 did not
impose.  Implementations are not required to enforce those restrictions;
the restrictions are instead guidelines for application writers who wish to
achieve the widest degree of portability.

Here is a partial list of things that a Forth-83 Standard Program could do,
that ANS Forth does not guarantee are still portable (on a given ANS Forth
implementation, there is a good chance that these things will work, but
there is no guarantee):

        1) Assume 16-bit stacks
        2) Assume byte addressing
        3) Use @ and ! with unaligned addresses
        4) Change the length of the text input by storing inte #TIB

It would be nice to develop a complete list.  Additions to the list
are solicited.

Mitch.Bradley@Eng.Sun.COM