I looked at the article, which begins with this premise:
The C version, without bothering to invent custom data types, requires no
thought:
void vadd(int *v1, int *v2, int *v3)
{
v3[0] = v1[0] + v2[0];
v3[1] = v1[1] + v2[1];
v3[2] = v1[2] + v2[2];
}
If the implementation is happy to put the data in memory, then it is very
likely to be OK to do this in FORTH as well. The misfire here is, that if
you're a hammer (FORTH), every problem looks like a nail (stack
exercise). As for pointers, everything's a pointer in FORTH, so there's no
time wasted trying to decide how to do it.
As mentioned, when something's too complicated, factor it down until the
stack is manageable. Sometimes there will be that one hairy
six-things-on-a-stack word. Those get treated as a special case. Work it
carefully, completely, document the hell out of it, and once it's done, put
it away and don't go back. Then write the rest of the program, which
should then be the "easy" part.
Even for that "FizzBuzz" thing--and I obviously don't get out much, since I
haven't seen that before--I would probably write a separate function to do
the interesting part, then pass a flag back indicating that nothing
happened and that the number is to be printed. I've known people who were
proud that they "got everything to fit into main()"
Barry
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
