Re: Immersion

[paul . ortais]

I had to create a small but rather complete imbedded Forth and opted for 
the interpreter/compiler to be an explicit state machine, for clarity 
and a bit of logical proof (safety concerns).
From this point of view, your dialog, and piles of it since Forth was 
born, is addressing some state transitions and exceptions, while in the 
SM world all states and transitions appear to be exceptions, but grouped 
in a logical way. The benefits I found is that in explicit SM mode
- no new situation is a problem, we rather complete the logic.
- execution is fast and traceable (light, self-tracing SM).
- compact and regular code.
- large complexity reduction.
- possibility of integrating several interpretation/compilation set of 
variants, not just interp/compile + exceptions everywhere.
- tricky modes like cross compilation is yet another SM branch to take
- the SM can step itself very easily, and in the same way the code, the 
execution/debug of which is just a journey through the SM. The very 
ability to step-by-step and debug or simulate the code was the initial 
requirement of the embedded design, and it appeared quickly that a 
single, very light do-it-all SM structure was nice to create and use.
Of course the simplified, regular form differs largely from the 
tradition, but many traditional words can still be attributed to the 
corresponding state.
(just to input a somewhat lateral view)
Paul

Le 2021-09-07 21:41, Brian Tiffin a écrit :

> Anton Ertl wrote: On Tue, Sep 07, 2021 at 02:26:57PM -0400, Brian 
> Tiffin wrote: Drop after-l.  Don't wait for the next key
> stroke to decide what state to put the console in.  It becomes a mental
> mode breaking point, with a distracting screen paint out of order.  
> There is some truth to that.  However, we actually want to extend the
> AFTER-L functionality: After a WHERE and a WW, NW, BW, or a backtrace
> and TT, NT, BT, cursor-left/cursor-righ should switch from one result
> to the next.
>
> Personally, I'd drop right to console mode, (where up/down arrow is
> history recall, not a new mental mode of scrolling text) and let
> programmers two-type the b<ret> and n<ret>.  The flash from source view
> to normal console with the stack status blue bar, is distracting.
>
> Just a suggestion.  Probably a thing that will sink into muscle memory, 
> Has not happened for me yet.
>
> I am open to alternatives.  Maybe we could make the after-l state look
> as if we are back in the text interpreter, and use some keys that are
> not normally used at an empty line in the text interpreter instead of
> the cursor-up/down keys.  Or equivalently, let the interpreter's
> EDIT-LINE do the AFTER-L functionality if one of the right keys are
> pressed.
>
> - anton
 Yeah, it's not an easy design balance, but I do think I'd prefer an
off-normal key to start scrolling, and just let after-l return to an ok
prompt.  That to me, would be less intrusive than current modal after-l.

Like all good art, can't explain it, but you know it when you see it.   
:-)

Regardless, another round of approval for the trends in Gforth with the
locate toolset.  Thanks for that.

Now just to find the magic that let's you ponder in forth while in an
editor.  Which for me always leads back to a block edit mode, or at the
least, find a way to have a forth scrub sheet to play with while in an
edit headspace.  I'm used to vim, and it doesn't really bend to allow
for thinking forth while typing forth.

And this is all just old guy yearnings from a time past.  But it was so
satisfying compared to the modern approach of external text files with
external tools, creating speed bumps that busts a mental state and
forces an ejection seat out of the zone.

Cheers,
Blue