Re: A Brief Look at History

Elizabeth D Rather <erather@xxxxxxxxx> wrote:
Jonah Thomas wrote:
Bruce McFarling <agila61@xxxxxxxxxxxx> wrote:
...
For people who are first learning Forth, animation is more
important> 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.
.

Relevant Pages

  • Re: A Brief Look at History
    ... separate window and show whenever it got updated. ... and work out how to debug it, you design the Forth animator and then ... and return stack, in a stack of views of in unsigned, signed and, if ... merrily around the source code display screen. ...
    (comp.lang.forth)
  • Re: Detailed Stack Information Patch [1/3]
    ... +#ifdef CONFIG_PROC_STACK ... the whole "display where the stack is" thing is ...
    (Linux-Kernel)
  • Stack Segment
    ... I'm trying to write a 16-bit DOS console app with MASM32 that converts ... It seems I need a STACK segment for the ... Converts a decimal digit input to binary and then display it ... Anyone know why the lines in the .stack segment aren't being ...
    (comp.lang.asm.x86)
  • Re: CAsyncSocket behaving multithreaded
    ... > Examine the debugger stack display when the unexpected OnReceive is hit. ... > an access violation or assert error, ... the unpredictable CAsyncSocket. ...
    (microsoft.public.vc.mfc)
  • Re: running rm cobol in a cron job
    ... SUPRESS command to suppress the window which says in the manual that it ... When I run the program manually from Unix, it does display a message ...
    (comp.lang.cobol)