Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uflorida!haven!uvaarpa!hudson!vivaldi!pmy
From: pmy@vivaldi.acc.virginia.edu (Pete Yadlowsky)
Newsgroups: comp.lang.forth
Subject: Re: type checking
Message-ID: <544@hudson.acc.virginia.edu>
Date: 2 Sep 88 14:38:55 GMT
References: <8808121826.AA23206@jade.berkeley.edu> <1575@crete.cs.glasgow.ac.uk> <535@hudson.acc.virginia.edu> <1389@ficc.uu.net>
Sender: news@hudson.acc.virginia.edu
Reply-To: pmy@vivaldi.acc.Virginia.EDU (Pete Yadlowsky)
Organization: University of Virginia, Charlottesville
Lines: 64

In article <1389@ficc.uu.net> karl@ficc.uu.net (karl lehenbauer#) writes:
>In article <535@hudson.acc.virginia.edu>, pmy@vivaldi.acc.virginia.edu (Pete Yadlowsky) writes:
>> Baggage, baggage and more baggage. Type checking?! *gag* I don't want
>> some uppity compiler protecting me from myself and telling me how I
>> may and may not use my computer. That stuff's fine for beginners, but
>> when it's time to cut loose and actually put the machine to work...

>Oh, please!  I once spent days finding a bug in a Forth program where a guy
>had done a store (rather than a c-store) into a CVARIABLE, clobbering an
>adjacent data byte (1802 polyForth with separate symbol table)

If you spent days searching for this bug, it must have been buried pretty
deeply into the code. Why was this? Forth code is supposed to be developed
incrementally, with careful testing all along. I think one of the reasons
large compilers need type checking is because they make incremental
development relatively difficult. Nobody wants to write a main driver to
test each and every subroutine. So they lean on the compiler. When habits
like monolith-writing and compiler-leaning are carried over into Forth,
disasters like the above occur.

>Don't get me wrong, I like 
>Forth a lot, but in Forth when one gets the number of arguments wrong, like
>in a loop, one typically blows the stack and crashes the machine.

Well, don't *DO* that!   :-)

>Again, I am not constrained by type checking; type checking catches bugs;
>type checking finds and notifies the programmer of *impossible* usages of
>data.  Although it is "telling me how I may and may not use my 
>computer," it is never appropriate to do word writes into byte fields, use 
>floating point numbers as pointers, pass ints to routines that want pointers 
>to floats &c &c &c  

Never? Ever? I think such decisions should be left to the application, not
to the compiler. Granted, the things mentioned above do sound weird and
maybe dangerous. But if I want to do "crazy" stuff, I should have that
freedom. Sometimes crazy is appropriate. Suppose I need a word that will
accept pointers or ints, and act according to some flag or code vector?
What if I want to access two bytes sometimes as bytes, sometimes as a
single word? C, for instance, will allow such things with pointer
coercion, but in Forth I can just go ahead and do it without worrying
about pleasing the compiler. This kind of freedom is, to me, worth
the price of being careful.

>(I just have to keep harping.  Consider the DO..LOOP, IF..THEN, BEGIN..REPEAT 
>security in Forth that insure control structures are properly nested.  Hey,
>that's the machine telling me what to do!?

No, that's the compiler saying "Hey, I don't know how to handle this", not
"Yo! Dummy! You can't do that."

>If I want to write a routine with
>a LOOP that doesn't have a DO, that's my business. :-)

Certainly is, and you certainly may. You'll just have to write your own
control structure, that's all. There's nothing inherent in the compiler
that disallows such a thing.



Peter M. Yadlowsky
Academic Computing Center
University of Virginia
pmy@vivaldi.acc.Virginia.EDU