Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ENG.SUN.COM!wmb
From: wmb@ENG.SUN.COM
Newsgroups: comp.lang.forth
Subject: Re: Essence of Forth
Message-ID: <9002161546.AA19812@jade.berkeley.edu>
Date: 16 Feb 90 03:16:02 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: wmb@ENG.SUN.COM
Organization: The Internet
Lines: 56

I stick by my claim that PostScript's strong typing is a fundamental
difference from Forth.  It is true that you can choose to think of
Forth stack items as "objects", but that does not change the fact
that PostScript's basic design is heavily influenced by its strong
typing and Forth's basic design is heavily influenced by its lack of same.

This does not imply that I think strong typing is necessarily "good"
(whatever than means) in all cases.  It just means that the difference
has far-reaching consequences for the language design.

By the way, Forth (unfortunately) does have operator overloading.
The AND operator is used both as a way to perform logical operations
both on bit vectors and also on truth value flags resulting from
comparison operators.  This has led to such hotly-debated concerns as
"should the value of a flag be 1 or -1", and how does this all work
on 1's complement or sign-magnitude machines (the answer: nobody is
really sure).  The + operator is used both for integer arithmetic
and also for address calculations (I'm sure people will dispute this,
but address arithmetic, in the general case, has different properties
from integer arithmetic).  Forth has a tendency to exploit "accidental"
properties of particular number representations that just happen to
be true for a subset of the computers in the world.  Forth's operator
overloading is thus "ad-hoc".


> Forth was designed pragmatically rather than as
> an embodyment of someone's theory of programming languages. It was
> designed by a programmer to solve programming problems. It is ad hoc
> in the best sense -- it is designed to produce the best practical
> solution to the problem at hand.

Forth as we know it was not "designed by a programmer".
A subset of what is now Forth was invented by a single programmer
Charles Moore (admittedly a rather large subset).  Then it evolved
in an ad-hoc fashion, to solve a rather-abitrarily limited subset
of programming programs, subject to dynamically-changing sets of
hardware constraints, many of which are no longer relevant.  There
were LOTS of fingers in the final pie.

In point of fact, the "designer of Forth" (CM himself) uses a variant
of Forth that is only approximately compatible with any other widely-
available Forth system.  Every time that I talk to Chuck, he has
changed his mind about some basic thing.  He just wants to do what
he wants to do this week, and he is smart enough to get by with it,
so more power to him.

I am in favor of pragmatic design, and a lot of Forth's good points
(in particular its general space and time efficiency) reflect this.
Some of Forth's not-so-good points reflect a narrow viewpoint about
the universe of programming problems and computer system environments.
This is reflected in one attitude that I heard expressed when I was
trying to push the ANSI memory allocation wordset: "The system I use
cannot benefit from [the proposed form of] memory allocation, and I
do not care about your application, so I will vote against the proposal".

Mitch