On Mar 17, 9:04 am, Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:
> Ah. You're talking about a toy Forth whose entire purpose is to show you
> how it works.
Yes ... though, indeed, if a topic of the tutorial sequence included
****ting, it could have a smaller toy forth and a larger toy forth ...
say, a 16-bit Forth and a 24-bit Forth, which on a modern desktop/
laptop would still have a very easily manageable 16MB of address
space.
> 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.
Oh, it has to start out animating the process, and only showing the
code that the student has written for it ... single step should be the
user hitting the brakes ... either interactively, or by setting a go-
into-single-step break point. Its not fun watching it if you *have* to
keep hitting space or whatever the single step command is.
> You're talking about something with multiplle windows that each get
> updated at the right time with just the right colors etc.
Precisely ... the "screen" is one window, the display of the code
being executed is a second window, the memory slider is a third
window, the stacks are a fourth window. Indeed, it does not have to be
a GUI ... if you define both the code text file margins and the
regular terminal display as both 64 columns wide, the whole thing
could be done within a 160x32 or more monospaced panel.
> 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.
Since the Forth that is being shown is an application running in
Forth, its as ****table as it gets coded ... its got a better shot of
being ****table than something similar that is trying to show what is
happening for the Forth that it is running on, rather than the Forth
that is running on it.
> 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.
It doesn't actually have to have any windowing stuff ... if ``0 0 AT-
XY'' maps to the correct position in the display, and output out of
range simply does not put anything anywhere, the user input and output
automatically goes to that part of the display ... the rest of the
display will automatically go where its put.
It would only do windowing stuff if windowing stuff was part of the
tutorial sequence.
> 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.
The way to get it ****table would be to do it in one, do it in a
second, use what you learned to ****t one of the two to the other
system, then keep ****ting it until its up on all the forth's in the
target range.
Or, implement it on gforth and distribute the whole thing as a package
under the GPL, then there is no need to worry about which one it runs
on.
What is ****table from the "Animatronic Forth" is the skill acquired in
visualising Forth in action. If the implementer learns something that
makes it easier to write a better Forth debugger for their favorite
production system, or an easier to use controller emulator for
umbilical Forth development, that would be a bonus.
|
