Hi Gerry,

My answer to question five, the following alternative approaches spring
to mind:

1 Repackage your C++ Forth as a DLL and host that within the VB
process. You should be able to provide a simple Forth/VB interface
based on TYPE, EMIT, ACCEPT, REFILL, etc. You will have to provide
other words (ie. functions/callbacks) for driving the GUI. A separate
makefile can be used for generating a standalone EXE Forth. You can
debug your Forth using the C++ debugger by specifying VB.EXE as the
debug process.
2 Provide a mapping to a C++ GUI library, such as MFC, within your C++
Forth. This sounds quite awkward and a lot of work.
3 Devise a foreign function interface within your Forth so that you can
make direct Win32 OS calls. Lots of work but will give the most
flexibility.

My view is that GUI coding can be very time consuming and fiddly.
Driving a simple bespoke interface such as an Othello board should work
fine using streams. If you are happy with your approach then stick
with that.

Adam Warner wrote:

I think this assertion relates to the psychology of Forth programming.
Their version of Forth takes the "virtual" out of VM. colorForth code
on a C18 is written to the C18's restrictions and strengths. It has few
keywords to remember and the set of words that are opcodes is small and
simple. Your restrictions are real hardware, not an abstract model.
It's not ANS so you don't treat it like ANS. Maybe that's why Jeff says
it's "Easier to program". That's not to say it can't be portable. You
can build a portable app on top...

Adam Warner wrote:

The documentation goes back almost twenty years. If you have been
following it you have seen the explanations of the conceptional
foundation for each of the changes introduced. Because much of
it is ancient history now probably the only place you will find it is
in the old pages at my site that document that fifteen year period
where Dr. Ting and I wrote the only documentation.

Take the removal of ELSE for instance.

This clearly had nothing to do with hardware in that an ELSE is
just a jump and the machines all have had jump instructions.

Like dozens of other things Chuck explained his reasoning.

People had experimented with factoring Forth code many different
ways and there were many debates about favoring using ; or
facoring using IF ELSE THEN or IF THEN or nested IFs and
BEGINs and FORs and DOs and CASE and RECURSE etc.

On Wed, 12 Jul 2006 09:50:45 -0700, Jeff Fox wrote:

Again, you can only use a bounded amount of stack with tail recursion or
the translation of a recursive definition into an iterative form.

A tail recursive Forth word will call RECURSE as the last thing it does
before exiting the word. A Forth compiler can translate this call into a
jump to the start of the word.

A tail recursive definition is typically harder to write than a non-tail
recursive definition. Here's an example I came up with within the
limitations of my Forth knowledge: Write recursive and tail recursive
words to naively sum the integers from 1 to the first element on the stack.

: non-tail-recursive-sum dup if dup 1- recurse + then ;

This is not tail recursive because + is called after RECURSE before
leaving the word. It is easy to understand because of the recursion:
If the TOS is non-zero, add the TOS to the return value of
non-tail-recursive-sum with input one less than the original TOS.

George Hubert wrote:

You're right.

So the problem with TO is using the same name for locals and for
nonlocal VALUEs. And that makes a problem for standardising VALUE .

Common practice. Hard to standardise. There are Forths that provide
both behaviors, but it was hard to require Forths to provide both
behaviors.

Ed wrote:

Since the ANS process required wide agreement, it couldn't help but be
a grab bag. It was only through great effort that it became as
consistent as it did.

They couldn't agree on ONLY ALSO . By putting that into an optional
extension they standardised its usage without forcing it on people who
didn't want it. And if you come up with something better you can
implement it in ANS Forth and give it away with your applications.