Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!SCFVM.BITNET!ZMLEB
From: ZMLEB@SCFVM.BITNET (Lee Brotzman)
Newsgroups: comp.lang.forth
Subject: Re: Standards and Portability
Message-ID: <8912012215.AA23449@jade.berkeley.edu>
Date: 1 Dec 89 22:14:10 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 116


John Wavrik writes:
>Lee Brotzman writes:
>> (Let's be realistic:  do you really think a requirement for specific
>> internal design would be adhered to by one of the most independantly minded
>> programming communities in existance --Forth programmers?  Any such Standard
>> would be dead on arrival.)
>
>Mathematicians tend to be independently minded too -- but at some point in
>history they decided to agree on the shapes used for the numerals and the base
>to be used for the number system. They also agree on a set of basic
>assumptions (axioms) and definitions. Without this agreement, progress in
>mathematics would be impossible.

   The key phrase here is "at some point in history".  Man was counting for
thousands of years before the numerals we use today became "standard".  There
were many systems of lines, curves, and dots to describe quantities.  Each
was sufficient to perform the job at hand.  The Roman numeral system is only
useful for quantities numbering in the few thousands.  In Roman times, who
needed to count farther than that?  Would it have been a good idea to freeze
the standard at that point?
   There is by no means a standard means of denoting numbers today, either.
The representation of quantities depends heavily on the application.  When
writing on paper, a circle can represent zero.  In a computer, a series of
transisters in a low voltage state represents zero.  The same quantity -- two
quite different applications and representations.
   By the same token, a Forth system destined for a small ROM chip might
prefer to use indirect threading because every byte counts, while a Forth
system on a VAX may be best suited to subroutine threading because of
speed considerations.  This doesn't mean that a Standard should only be
defined for one and not the other.

> It would not be considered creative in
>mathematics to change the shape of 8 (arguing that a different shape would
>allow us to write it more quickly) or to suggest that we change the number
>base from 10 to 12. And it would be total disaster to leave such foundational
>things "implementation dependent". The foundations on which we agree are
>highly portable and are extensive enough to support the superstructure of the
>subject. Lots of independent minded people have made contributions to
>mathematics without feeling stifled by sharing a common language and a common
>set of basic assumptions on which to build -- they show their independence at
>a higher level.

   Mathemeticians, like good programmers, make use of "information hiding".
The axioms you mention are not stated in terms on numerals alone, but have
other symbols (e.g. greek letters) which represent a class or special
quantity.  These symbols are also "implementation dependant".  When an
astronomer refers to right ascension and declination (a form of celestial
coordinates) he uses the greek letters alpha and delta.  Delta can have
a very different meaning when used in a differential equation.  (I almost
washed out of a Diff. Equ. course in college because the professor preferred
his own system of notation to that in the text.)  Mathematical notation isn't
standard.
   Most papers have a set of definitions to describe which symbols mean
what.  This is analogous to documenting implementation dependant features.
   Axioms are "truths", not just ideas everyone thinks is a good place to
start.  Theorems can be proven by applying the axioms.  Your analogy simply
doesn't apply to the question at hand: annointing a single Forth architecture
as the only Standard one.  There is no single architecture that is better
than all others.  To state otherwise is only opinion, not truth.

>
>There is an historical precedent for what I am suggesting. About 10 years ago,
>a group of independently minded programmers decided to make a new language
>available to the general public. They implemented their model on about a dozen
>of the most popular processors of the time. Most people who got past the
>unconventional nature of the language found it almost supernaturally powerful.
>(Much of the supernatural power derived from the fact that the implementation
>was part of the language.) It was also supernaturally portable: the main
>barrier to getting code written on one computer to run on another was getting
>the code transferred (modems were rare and expensive at the time).

   I presume that you are referring to FIG Forth here.  The FIG model was
precedant setting, but is no longer in widespread use.  It has been quite a
while since I used FIG Forth, but I believe that even it had certain
implementation differences between processors.
   Let's get back on track here.  You have stated that the standard should
identify one architecture, specifically a threading scheme, and stick to it.
Could you please supply us with your choice and a supporting argument for
excluding any other implementation from acceptance?  Also, should all other
architectural design features be rigidly specified?  I'm referring to the size
of a stack element, the allowable fields and format of word headers,
bit-ordering in integers, floating point representation, permissible address
space, character codes, whether Forth runs as an operating system or through
the services of a host operating system, etc.
   The current ANSI Basis Standard is designed so that nearly all of these
"implementation dependant" features can be used transparently across all
systems, even though the underlying architectures may be wildly different.
   You said yourself that "you do not add power to a language by removing some
of its features and declaring them to be 'decidedly non-standard'."  The ANSI
TC has added a lot of power to the Forth 83 standard, especially by lifting
the hard-coded 16-bit stack element size and adding standard sets of floating
point and file manipulation words.
   Declaring a feature "non-standard" doesn't remove it from the language,
it only serves to mark a place where the specific design of a system may
cause problems when porting code.  These areas are explicitly described
as completely as possible in the Basis.  I think that the ANSI TC is being
quite responsible in their efforts to make the Standard as encompassing as
they can while at the same time taking care not to break a hell of a lot
of Forth code.
   Forth, like all aspects of electronic computing, is still in its infancy.
There is a lot of room for growth.  Perhaps in a few thousand years, Roman
numeral Forth and Arabic numeral Forth will finally consolidate on a single,
perfect solution.  Until then, it's just too much fun looking for the ultimate
Forth to call an end to the search.

>
>                                                  John J Wavrik
>             jjwavrik@ucsd.edu                    Dept of Math  C-012
>                                                  Univ of Calif - San Diego
>                                                  La Jolla, CA  92093
-- Lee Brotzman (FIGI-L Moderator)
-- BITNET:   ZMLEB@SCFVM
-- Internet: zmleb@scfvm.gsfc.nasa.gov
-- The government and my company don't know what I'm saying.
-- Let's keep it that way.