🚀 go-pugleaf

In article <2917@sunybcs.UUCP> sunybcs!ugbowen (Devon Bowen) writes:
>HELP! I'm planning on writing a forth interpreter in C during my
>Easter break. I do not, however, have the the documantation on the
>most resent standards of the language. If anyone has these on file,
>please send me a copy through E-mail. Thank you...

I was about to post the same query; if you get any replies please
send me a copy (if you receive the entire standards document) or
post a summary (if you receive a pointer).  My situation is that I
have already written a forth (interpreter? compiler?), but it was
based on a curious mixture of FORTH-79, FIG-FORTH, Apple GRAFORTH,
and many of my own ideas; I'm trying to move it a little closer to
the standard (which is now FORTH-83, right?).

Some examples for discussion.  The word to output one character
was called {emit}, {echo}, or {putc} in my three sources.  In my
implementation I called it {c.}, since "c" means character and "."
means output.  Does this make sense to the rest of you out there?

I'm currently using {dp} for the dictionary pointer variable (so
{dp} gives you the address (of the pointer), as with any variable).
I have the definition
	: here		dp @ ;
to get the value of the pointer.  I'm not convinced it deserves
a word of its own, especially since "here" is no shorter than
"dp @".  Now I'm thinking about keeping the dictionary pointer in
a hardware register.  Since registers have no address, I'd have
to abandon {dp}.  Could I just define {dp@} and {dp!}?  I'm
already doing that with the (data) stack pointer, i.e. I have
{sp@} and {sp!} (which are, of course, dangerous things to play
with).

I'd better clarify that last question.  Of course I "could" define
{dp@} and {dp!}, what I really mean is "would it still be forth?"
or something like that.  I used the book _Threaded Interpretive
Languages_, by R. Loeliger, as a guide; he said something to the
effect that anything you want to put in a TIL is OK -- change it
if you don't like it.  Which is why my {do} statement will execute
zero times if you ask it to.

>Oh, my current version of forth (not a very good one) does not
>support recursion. Is this standard for forth, and if so, why
>no recursion??

My experience is that _indirect_ recursion is forbidden because a
word must be defined before it can be used; direct recursion works
because when you define a word, its name goes into the dictionary
immediately and hence becomes usable even within its own body.
I don't know about the official story on recursion in forth, but
I'd guess your "current version" is, as you said, "not very good".

Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint.