trolfs@vax1.tcd.ie (Tommy) (05/30/89)
Request:
I was told that there was a 5 part version of Forth for the Mac posted
awhile back (not pocketForth).
Could someone let me know if they have it? Please?
Question:
I was very taken by the articles in Forth Dimensions (XI/1) on extra
stacks for Forth and local variables. I'd never really thought about
using extra stacks and even less about local variables, so it was a
real eye opener. Actually, this was my first time getting Forth
Dimensions and it gives you some idea of how isolated I am.
I know that this topic must have been discussed to death before, but
I'm very interested to hear what you (The Netforthers) have to say
about using extra stacks and local variables.
One of the things discussed was the freeing of the Return stack from
holding anything other than return addresses. This idea appeals to me
as I always feel uneasy about storing things there. What really
interests me though is, if more stacks are needed (and I think they
are), what is the minimum number and how can they be best used? (ie,
is a floating point stack good programming or - for uniformity - should
all parameters be passed only on the parameter stack?)
Another thought is the use of local variables. Are more people looking
to local variables for easier coding and better readability? And if
done well, couldn't local variables make for faster run-time code?
Probably, if you had complicated stack manipulations. But even if they
don't, their readability would make Forth a LOT more palatable to
non-Forth programmers (which would help Forth's image no end).
I for one think that Forth's parameter passing and manipulation and also
it's stack configuration, should to be built on and expanded if it is to
be considered a 'serious' alternative to present day compiled languages.
Well, that's what I think (:-). It would be nice know what the experienced
Forth programmers on the Net think. Are more stacks needed? Where can they
benefit best? Are local variables overall useful or do they take away
from the Forth philosophy of "Simple is beautiful"? (Though, I thought
John Hayes's implementation, in FD p18, looks very simple and improves
readability greatly, where as some of the other implementations didn't.)
But, the main question that I'm interested in is "Are extra stacks and
local variables going to be made standard?".
Then again, maybe it's the Forth novices who are in a better position
to know what is needed to make Forth an easier pill to swallow. After
all, they (we) still have the bitter after taste.
Here is a very simple example of John Hayes's local variables:
: add ( a b -- a+b )
{ / { mark start of new scope
local b / local creates the local variable b and
local a / pops the top of stack is in to it
a b +
} / } releases local variables
;
--
Tommy $P-)
E-mail: trolfs@vax1.tcd.ie
:If you don't get a reply, let me know. Sometimes my mail enters the TZ:
: FLAMES HIGH LOW DO I TURN-DIAL LOOP ; IMMEDIATEbouma@cs.purdue.EDU (William J. Bouma) (05/31/89)
In article <44212@vax1.tcd.ie> trolfs@vax1.tcd.ie (Tommy) writes: > Another thought is the use of local variables. Are more people looking > to local variables for easier coding and better readability? And if > done well, couldn't local variables make for faster run-time code? > Probably, if you had complicated stack manipulations. But even if they > don't, their readability would make Forth a LOT more palatable to > non-Forth programmers (which would help Forth's image no end). > I for one think that Forth's parameter passing and manipulation and also > it's stack configuration, should to be built on and expanded if it is to > be considered a 'serious' alternative to present day compiled languages. > As several of you know, my personal version of FORTH looks a bit different from the standard. I handle local variables in the following way: 1. parameter passing ok, : partest ( -a -b c -d -- c ) a @ . b @ . d @ . ; partest ok, 1 2 3 4 partest 1 2 4 ok, . 3 ok, As you can see, the () really do something in my version. What it does is assign local variables a, b, and d and give them the corresponding (positionally) values on the stack. Those variables without a dash in front are just ignored, thus most code where () enclose comments will work without modification. 2. local variables and words ok, : loctest variable a variable b : add + ; ... ; loctest ok, 5 6 add . Error: undefined word "add" executed. ok, 5 6 loctest>add . 11 ok, b @ . Error: undefined word "b" executed. ok, 3.14159 loctest>b ! ok, I implement this in a simple way by just giving each word a pointer to a sub-vocabulary. When a word is being defined, its own vocabulary becomes the one searched first and the one where new definitions are stored. I also allow the '>' syntax to specify precisely the word desired. To circumvent the normal vocabulary search order just type vocab1>vocab2>...>vocabn>word. The only problem with this scheme is that local variables do not work the "normal" way. New instances are NOT created each time a function is called, thus recursive functions should be careful in using them. > Forth programmers on the Net think. Are more stacks needed? Where can they > benefit best? Are local variables overall useful or do they take away > from the Forth philosophy of "Simple is beautiful"? (Though, I thought > John Hayes's implementation, in FD p18, looks very simple and improves > readability greatly, where as some of the other implementations didn't.) > But, the main question that I'm interested in is "Are extra stacks and > local variables going to be made standard?". > I do not see a need for more stacks. Can you give an example of why you think there should be more? If you really want more, the best way I can think of is to have a notion of a current stack that everybody uses. To start the only stack available is MAIN. You type "stack a-stack" to create a new stack (word) called 'a-stack'. By executing a-stack the current stack everyone uses becomes a-stack. After reading the Forth83 standard I must admit to being unimpressed. I see no real improvement over the old 78 standard I played with as a kid. It still seems to be targeting for micros and machines with very little memory. In a way this is good, because it is an excellent language for such machines and there are already plenty of big languages for big machines. Forth is, however, the most elegant way to write an interpreter. -- Bill <bouma@cs.purdue.edu> || ...!purdue!bouma