Bruce McFarling <agila61@[EMAIL PROTECTED]
> wrote:
> Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:
> > I think it was Win32Forth that would put a stack diagram in a
> > separate window and show whenever it got updated. A nice tool to
> > help build the one you want. I used it for a little while, but it
> > was annoying. My students never used it. I never noticed anybody
> > else use it or talk about using it, but since it's a debug tool they
> > might just not mention it.
>
> No, that's a debug tool.
>
> It would look like a multi-pane debugger, but rather than have a Forth
> and work out how to debug it, you design the Forth animator and then
> write a Forth that you can animate well. If you have a 32 bit Forth,
> then make the animated Forth 24 bit or 16 bit, so that it can be
> wholly contained in a closed space inside the animation program.
Ah. You're talking about a toy Forth whose entire purpose is to show you
how it works.
> This is like the "Visible Man" and "Visible Woman" models they use in
> physiology. The executable code show up as one color, the comments as
> another, the cursor is in the spot in the source inside the word
> currently being executed, after execution has passed a word, it gets a
> slightly darker shade of its original color. Over in the panel in the
> left hand side is the display proper, beneath the two screens, facing
> each other just across the the middle of the screen, is the datastack
> and return stack, in a stack of views of in unsigned, signed and, if
> in the character range, character. The reverse color highlight hops
> merrily around the source code display screen. Of course, when
> interpreting the command line, the SOURCE string shows up in the
> display, with the cursor hopping merrily in just the same way.
>
> Between the two main displays is the memory peek-hole, "lower"
> addresses at the bottom, "higher" addresses at the top. Normally the
> memory peak-hole follows HERE through the codespace.
>
> I wouldn't try to write it, first, because its probably beyond my
> reasonable ambitions, and second, because I am not interested in
> teaching Forth in a classroom setting. But if I had had something like
> that when I was learning Forth, I would have learned more quickly.
It was pretty easy to hook into a simple Forth system to have it
single-step. Have it display the name and stack diagram for each word on
one level on the return stack. Let the user choose whether to go deeper.
Variables can display their current contents each time they're
referenced. Etc. Easy to do. Nobody wanted to use it, including me.
You're talking about something with multiplle windows that each get
updated at the right time with just the right colors etc.
If I was to do something like that I'd like it to be ****table. The way I
did it simply took a lot of knowledge about the Forth compiler, and
wouldn't ****t to other Forths at all easily.
So it might be better to do your project in some languagea that's
optimised for windowing stuff and that ****ts to multiple hardware and
OSes. TclTk is my first thought since it shares some of Forth's
advantages, but Python etc might work well.
Alternatively, you might find a single Forth that's been ****ted to
MSWindows, Mac, Sun, Linux, and OSX and is being actively maintained in
them all, and write the demo Forth in that.
|
