I've been looking at the various language specifications for Forth,
Joy, etc trying to figure out what the minimal operators are that can
be combined to form an entire set of operators (if desired).
I think, for Forth, a minimal list would be:
drop [discard top of stack; $ in Befunge]
depth [height of stack before this operation]
dup [duplicate TOS; : in Befunge]
roll [move Nth item to TOS and rotate others down]
-roll [?? I assume "move TOS to Nth position and rotate others up"]

assuming that : swap 2 roll would correctly swap the top two stack
values. Im pretty sure that every other stack operation can be
performed from this set. Can anyone confirm this?

Actually, it probably should behave more like a list - be able to
randomly add or remove elements anywhere in the stack. A traditional
stack does just have push and pop, but sometimes more may be needed.
That's the reason, Im guessing, that most stack-implemented languages
include more than just push and pop.
The other option is having the double-stack arrangement such as Joy,
which allows you to move items from the primary stack to a secondary
"helper" stack.

Actually, it probably should behave more like a list - be able to
randomly add or remove elements anywhere in the stack.

A traditional
stack does just have push and pop, but sometimes more may be needed.
That's the reason, Im guessing, that most stack-implemented languages
include more than just push and pop.

The other option is having the double-stack arrangement such as Joy,
which allows you to move items from the primary stack to a secondary
"helper" stack.

see brent kerby's "the theory of concatenative combinators":
http://tunes.org/~iepos/joy.html

Big aside:
I'm developing a filtered version of Befunge that removes some of the
extraneous details (I've always disliked the ? - random vector -
operator, it bugs the bejeebus out of me),

and I wanted to develop some
other paradigms, add a couple more stack operators so that the language
wouldn't have to rely on programming-space-storage ('a great big
honking number of registers').

Big aside:
I'm developing a filtered version of Befunge that removes some of
the
extraneous details (I've always disliked the ? - random vector -
operator, it bugs the bejeebus out of me),

Then don't use it. I think it's only supplied because
otherwise
anyone who wanted a PRNG in Befunge would have to write one, and that
could be quite tedious. And PRNG-based programs are quite popular in
toy languages, I've noticed.

and I wanted to develop some
other paradigms, add a couple more stack operators so that the
language
wouldn't have to rely on programming-space-storage ('a great big
honking number of registers').

(You know that Funge-98 actually gives the programmer a countably
/infinite/ number of registers, because Funge-space is infinite,
right?
And IMLE it's very easy to simply "reserve" row 0 for data storage
stretching off to infinity, and that gives you the tape of a Turing
machine, or the linear address space of a "normal" computer. So I'm
not sure what else you could want.)
(Unless it's explicit support for recursion somehow. That would
be
interesting, I think, if it were done well. But I can't immediately
think of any way to do it well.

Big aside:
I'm developing a filtered version of Befunge that removes some
of the extraneous details (I've always disliked the ? - random
vector - operator, it bugs the bejeebus out of me),

Then don't use it. I think it's only supplied because
otherwise anyone who wanted a PRNG in Befunge would have to write
one, and that could be quite tedious. And PRNG-based programs
are quite popular in toy languages, I've noticed. ;-)

The reason I dont like it (and don't trust it) is that it's not
supposed to be a psuedo-random direction, but a RANDOM direction
(according to the Funge-98 specification),

which is impossible,

but the specification gives no clear rules as far as what the PRNG
that would actually implement it should do (a RNG which counts 1, 2,
3, 4... is still an RNG, just a very bad one), plus there's no rules
or control for seeding.

I think RNGs should be more thoroughly implemented, and
yes, "toy" languages often develop PRNGs. It's hard not to view Befunge
or any funge for that matter as anything BUT a toy language, although
any languuage that could be turing complete shouldn't be viewed as a
toy language. BF, in all its ridiculous simplicity, is a pretty
interesting language from a theoretical point of view.

(You know that Funge-98 actually gives the programmer a countably
/infinite/ number of registers, because Funge-space is infinite,
right? And IMLE it's very easy to simply "reserve" row 0 for data
storage stretching off to infinity, and that gives you the tape of a
Turing machine, or the linear address space of a "normal" computer.
So I'm not sure what else you could want.)

Again, the Funge-98 spec says that the addressing range in each
direction should be the limit of the numbers represented by a single
cell.

This is the same model followed by C and C++, except that they
provide a black-box routine for seeding the PRNG as well. IMNSHO,
this is actually a /good/ thing. Suppose you specify that your
language will mandate a Mersenne Twister PRNG. Murphy's Law states
that three months after your first gamma release, somebody will
discover a flaw in Mersenne Twisters and you'll have to scrap that
part of your standard. With the C "black-box" model, the language
remains unchanged --- you just tell everyone to watch out for
obsolete
implementations, and get on with the more important things.

In fact, as it stands, there's nothing preventing a Funge
implementation from using *real* random numbers for '?', instead of
pseudo- ones. There are plenty of online sources of randomness,
plus /dev/urandom on *nix machines. No reason to rely on any
particular PRNG at all!

I think RNGs should be more thoroughly implemented, and
yes, "toy" languages often develop PRNGs. It's hard not to view
Befunge
or any funge for that matter as anything BUT a toy language,
although
any languuage that could be turing complete shouldn't be viewed as
a
toy language. BF, in all its ridiculous simplicity, is a pretty
interesting language from a theoretical point of view.

"Interesting" and "toy" are not incompatible designations, as any
child will tell you.

(You know that Funge-98 actually gives the programmer a
countably
/infinite/ number of registers, because Funge-space is infinite,
right? And IMLE it's very easy to simply "reserve" row 0 for data

storage stretching off to infinity, and that gives you the tape of
a
Turing machine, or the linear address space of a "normal"
computer.
So I'm not sure what else you could want.)

Again, the Funge-98 spec says that the addressing range in each
direction should be the limit of the numbers represented by a
single
cell.

But the Lahey-space model in the Appendix works with infinite
volumes,
and the possibility of "infinity" bytes per cell [sic] is explicitly
mentioned in the text for the 'y' instruction. 'Sides, I think
infinity
is more elegant.

fantastic! That's exactly what I was looking for, although I would have
never known that that was the actual theory I wanted. Thanks!