ugbowen@sunybcs.UUCP (Devon Bowen) (03/09/86)
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...
Devon E
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??kwh@bentley.UUCP (KW Heuer) (03/11/86)
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.
calvin@stc.co.uk (Calvin Sambrook) (03/14/86)
In article <625@bentley.UUCP> kwh@bentley.UUCP writes: >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". If your forth allows it you can get around this by defining one of the words as a dummy ie. : firstword ; The name is now in the dictionary so you can use it in the definition of another word ie. : secondword firstword ; If you now edit the first word it can reference the second ie. : firstword secondword ; A quick redefine will then sort out the dictionary and hey presto recursion. As I said, your forth may prevent you doing this, mine allows it. I'm not sure what the standard(s) say about it. -- calvin