On Mar 18, 8:03 am, Bruce McFarling <agil...@[EMAIL PROTECTED]
> wrote:
> 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.
How about implementing it as a web server?
> 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.
|
