Path: utzoo!attcan!uunet!husc6!bloom-beacon!bu-cs!purdue!decwrl!ucbvax!pasteur!helios.ee.lbl.gov!lll-tis!lll-ncis!lll-lcc!unisoft!hoptoad!vixie!smegma!mdg
From: mdg@smegma.UUCP (Marc de Groot)
Newsgroups: comp.lang.forth
Subject: Re: New Features for Forth
Message-ID: <509@smegma.UUCP>
Date: 2 Oct 88 07:27:06 GMT
References: <1593@crete.cs.glasgow.ac.uk> <810002@hpmtlx.HP.COM> <1654@crete.cs.glasgow.ac.uk>
Sender: mdg@smegma.UUCP
Reply-To: mdg@smegma.UUCP (Marc de Groot)
Organization: A moving point in 4-space
Lines: 26

In article <810002@hpmtlx.HP.COM> adam@hpmtlx.HP.COM ($Adam Kao) writes:
>I NEED to know what's going on in some memory location to fix my bugs.
>That's why there are so many debuggers for C and so few for Forth.

WHOA!  Hold on thar a *minute*.

I write debuggers in Forth for fun -- and for a living too.  Forth is the
easiest language to write debuggers for -- bar none!  LISP comes close, but
doesn't make it.

Having a simple, regular structure for executable objects in Forth gives
it a unique ability to refer to itself.  Moreover, single-steppers can
be thrown together trivially.  C simply does not lend itself well to
interpretation or single-stepping.  SDB is a good try, but does not allow
control of the execution within a single line of source.  It has other problems
as well, which are implementation problems (bugs) rather than design problems.

Unlike Forth, C has a "rich" syntax which makes it more difficult to write
interpreters for.  The language was created with traditional compiler
concepts in mind, and is poorly suited for other approches.

-- 
Marc de Groot (KG6KF)
UUCP: uunet!hoptoad!smegma!mdg         Internet:mdg@smegma.UUCP
"The pathology is to want control, not that you ever get it, because of
course you never do." - Gregory Bateson