Path: utzoo!yunexus!ists!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.lang.forth
Subject: Re: Forth Implementation (long)
Keywords: Forth implementation
Message-ID: <7036@ficc.uu.net>
Date: 17 Nov 89 17:55:15 GMT
Article-I.D.: ficc.7036
References: <5172@sdcc6.ucsd.edu>
Reply-To: peter@ficc.uu.net (Peter da Silva)
Organization: Xenix Support, FICC
Lines: 30

You're right. If you can't add code words and you're too busy to fix
the readily available C source to your C Forth you're going to have
a loss of performance. But, really, that's all that you're going to
lose. And that loss of performance may be acceptable:

	a. It may mean that you can run code on a 33 MHz 68030
	   or SPARC instead of a 2 MHz 8051 (or whatever) or on
	   an emulator.

	b. It means you can timeshare your Forth development
	   instead of having to do all your testing on the testbed
	   system.

	c. It means you can test your code in a safe environment.
	   When developing Forth under UNIX I would often do a !fork()!
	   after loading a bunch of words before trying something.
	   That way if I blew it I'd be back in the parent environment.

	d. It means you can get a working Forth environment up on
	   a new development system in a matter of minutes rather
	   than days.

I don't see the point in beating this particular dead horse any more. We
accept that there are disadvantages to Forth under C. But that doesn't
make it a "toy".
-- 
`-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.hackercorp.com>.
 'U`  --------------  +1 713 274 5180.
"vi is bad because it didn't work after I put jelly in my keyboard."
   -- Jeffrey W Percival (jwp@larry.sal.wisc.edu)