Path: utzoo!attcan!uunet!van-bc!ubc-cs!alberta!aunro!idacom!andrew
From: andrew@idacom.uucp (Andrew Scott)
Newsgroups: comp.lang.forth
Subject: Re: various BASIS10 remarks & suggestions
Message-ID: <1990Mar23.224117.29979@idacom.uucp>
Date: 23 Mar 90 22:41:17 GMT
References: <1637@tuegate.tue.nl>
Organization: IDACOM Electronics Ltd.
Lines: 41

> 4. COMPILE
>    Can anyone explain to me why a definition of
>    : COMPILE    >R  DUP 3 +  >R  C@ C, ( store the JSR ) @ , ;
>    wouldn't run on subroutine threaders?

The main problem is that COMPILE assumes that it is followed by a "jsr xx",
when many (most?) subroutine threading Forths optimize certain code sequences.

For example, if the code for DUP is inlined for speed when it is compiled, then
	... COMPILE DUP ...
won't work very well.


I'm now of the opinion that COMPILE should have been defined similar to
EXECUTE:

	COMPILE  ( execution token -- )

COMPILE DUP would be replaced by ['] DUP COMPILE.

While we're at it, let's get rid of [COMPILE] also:

	['] IF EXECUTE  replaces  [COMPILE] IF

Both of these work fine with optimizing subroutine threaded Forths.


The problem with COMPILE and [COMPILE] (and even BASIS's POSTPONE) is that they
are all adding more prefix operators to the language.  It's much more useful
for words to take their arguments from the stack instead of the input stream
(like [COMPILE] and some versions of COMPILE).  The examples above show that
' and ['] (or just ' if you like state smart words) help factor things.


Rob Chapman has implemented both these ideas in his bot-Forth.  I'm doing the
same for my current project.
-- 
Andrew Scott	| mail:		andrew@idacom.uucp
		| - or -	{att, watmath, ubc-cs}!alberta!idacom!andrew
		| - or -	uunet!myrias!aunro!idacom!andrew
Mark Messier: he's gotta have Hart!