Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ucsd!rutgers!bellcore!tness7!tness1!sugar!ficc!karl
From: karl@ficc.uu.net (karl lehenbauer#)
Newsgroups: comp.lang.forth
Subject: Re: type checking
Message-ID: <1423@ficc.uu.net>
Date: 7 Sep 88 20:20:11 GMT
References: <8808121826.AA23206@jade.berkeley.edu> <1575@crete.cs.glasgow.ac.uk> <544@hudson.acc.virginia.edu>
Organization: Ferranti International Controls
Lines: 30

In article <544@hudson.acc.virginia.edu>, pmy@vivaldi.acc.virginia.edu (Pete Yadlowsky) writes:
> 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. 

Not all bugs can be found by unit testing.  Some bugs do not manifest themselves
until some other criteria are met, perhaps after the system is installed, even
in Forth.

> 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?

In C, unions exist for this purpose.

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

You sure there's a difference?  Not for the control structure example, I think.
Anyway, *I* still want it to not let me do things that can't possibly be valid,
such as my examples before: storing words into character variables, comparing
integer and floating point without a prior conversion, calling a routine that
expects a pointer with an integer, &c &c

Sorry, but I think most computer scientists will agree that while Forth provides
a very nice programming environment, it is not a particularly good programming 
language.
-- 
-- +1 713 274 5184, uunet!ficc!karl
-- Ferranti International Controls, 12808 W. Airport Blvd., Sugar Land, TX 77478