Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!ut-emx!hasan
From: hasan@ut-emx.uucp (David A. Hasan)
Newsgroups: comp.lang.forth
Subject: Re: Merits of Forth
Message-ID: <46038@ut-emx.uucp>
Date: 22 Mar 91 23:50:20 GMT
References: <1991Mar21.192611.28487@src.honeywell.com> <17792@crdgw1.crd.ge.com> <1991Mar22.161424.5517@src.honeywell.com>
Distribution: na
Organization: UTexas Center for Space Research
Lines: 37

In article <1991Mar22.161424.5517@src.honeywell.com> lowry@SRC.Honeywell.COM (Dave Lowry) writes:

>No, I don't need the language to tell me that : 1 2 ; is stupid.  I also
>don't need my circular saw to tell me that it's stupid to stick my 
>fingers in the blade, but I leave the blade guard on anyway.
>

This is indeed a compelling argument and no doubt the kernel
of the motivation for strong typing in other languages.
However, consider this (just to play with the analogy for a
second):  the blade guard, as useful as it is, is not the saw.
It is a feature.  If you want the protection it provides, 
make sure you get a saw that has a guard on it.

I suppose this is *exactly* what lint is supposed to provide
for C programmers (one of which I am _not_).   If I wanted to
benefit from this degree of protection in FORTH, I'd hack with
the words the read the input stream.  But just because *I*
wanted that kind of protection doesn't necessarily mean that I
should impose it on others.  

Of course, a large software organization may have very strict
guidelines which amount to constraints on the order of a blade
guard.  I suspect such an organization would not be using
FORTH in the first place.

Don't get me wrong.  I'm not against the kind of protection
you're talking about.  But a key feature of FORTH is its
extensibility.  I suppose that's my answer to the question
that started this thread (which was "what do you think of a
language which allows redefinition of "one" to be "two" as in
: 1 2 ;).  The fact that the language allows this kind
of abomination reflects a prejudice in favor of letting the
programmer define his/her own safety constraints.
-- 
 |   David A. Hasan
 |   hasan@emx.utexas.edu