Elizabeth D Rather <erather@[EMAIL PROTECTED]
> wrote:
> Jonah Thomas wrote:
> > Bruce McFarling <agila61@[EMAIL PROTECTED]
> wrote:
> ...
> >> For people who are first learning Forth, animation is more
> >im****tant> than illustration. A 16-bit sandboxed Forth, showing the
> >text of the> word its executing, the state of the data and return
> >stacks, a memory> peephole, a display of command line input and
> >output ... all of course> inside the Forth that is providing the
> >services ... have it run> showing the movement through the files
> >loaded by the learner, with> controls to increase and reduce the
> >pace, run full speed through to> checkpoints (the beginning and end
> >of each loop construct would be> automatic checkpoints), single step
> >mode, etc.
> ...
>
> > I did that, and I expect a lot of others did too. I never used it.
> > My students never used it. I didn't notice anybody use it.
> ....
>
> I doubt that full automation is useful enough to justify the effort.
> Open Firmware's standard specified a debug tool that is a perfect
> example of what folks say they want. But neither IBM nor Apple felt it
>
> was sufficiently useful to fully implement it.
Depending on the implementation, it doesn't have to be much work. With
an indirect-threaded Forth, it's easy to modify the inner interpreter.
Get an xt, display its name, display the stack, wait for a keystroke.
Revise WORD etc to display a word of text in quotes before continuing.
Etc. Simple, shows what's happening. There have been times it would
probably have found bugs faster than I found them without it. I couldn't
make myself keep using it after I was sure it worked.
> Swiftforth shows the current state of its data stack in a pane at the
> bottom of its command window. That's sometimes very helpful.
I remember a Forth that put that in a vertical window that covered up
part of the main window. It was so annoying after a little while I
figured out how to turn it off.
For myself, displaying the stack depth at the CLI prompt is so useful if
I find myself using a Forth that doesn't do it, I want to figure out
how to make it do that. I don't need a permanent stack diagram enough to
waste a line of text on the monitor. .S is usually enough although I can
see the stack might be useful when a program is waiting for input.
Still, the original thought was for beginners, for the kind of
beginners who currently reject Forth. They might actually like tools
that I wouldn't use. And they can't build those tools for themselves
because they don't know enough, and they give up Forth before they learn
enough.... It's hard to be sure what they need. You don't really find
out until something works. And it's possible they'd just be bad Forth
programmers regardless. "Never teach a pig to sing. It frustrates you
and annoys the pig." But we were discussing ways to make a Forth-like
language more accessible, and that means finding ways to make it
acceptable to people who normally wouldn't want it.
|
