On 4/10/22 12:12 AM, dxforth wrote:

> It's beneficial to automatically see the results of operations at each step -
> much the same way as a calculator or debugger does:
>
> 1 2 3 ok 1 2 3 <
> + ok 1 5 <
> - ok -4 <
> . -4 ok
> pi ok 3.141593E0 <f
> 2e f* ok 6.283186E0 <f

Agreed. MacForthonVFX with judicious use of traceon and traceoff:

-Doug

traceon debug off
: test begin 1 2 3 + - . pi 2e f* quit again ;
traceoff

debug on
test
begin ( 0 )
1 ( 1 ) \ 1
2 ( 2 ) \ 1 \ 2
3 ( 3 ) \ 1 \ 2 \ 3
+ ( 2 ) \ 1 \ 5
- ( 1 ) \ -4
. -4 ( 0 )
pi ( 0 ) ( 1 ) \ 3.141593
2e ( 0 ) ( 2 ) \ 3.141593 \ 2.
f* ( 0 ) ( 1 ) \ 6.283186
quit

"minf...@arcor.de" <minforth@arcor.de> writes:
> For my taste CLS is too close to that old CLearScreen.
> I use .. quite often and like it because it is just a quick double-tap
> on the keyboard adjacent to the space bar.

Me too, until I added input line editing to ForthOS.
Now ^L (control-L) has taken over.

Andy Valencia
Home page: https://www.vsta.org/andy/
To contact me: https://www.vsta.org/contact/andy.html

On 11/04/2022 20:11, Marcel Hendrix wrote:
> On Sunday, April 10, 2022 at 6:12:21 AM UTC+2, dxforth wrote:
>> On 9/04/2022 21:06, Marcel Hendrix wrote:
>> > On Saturday, April 9, 2022 at 6:25:20 AM UTC+2, dxforth wrote:
> [..]
>> It's beneficial to automatically see the results of operations at each step -
>> much the same way as a calculator or debugger does:
>
> FORTH> : ok .S ; ok
> FORTH> 1 2 3 ok
> Data: 1 2 3 ---
> System: ---
> Float: --- ok
> [3]FORTH> + ok
> Data: 1 5 ---
> System: ---
> Float: --- ok
> [2]FORTH> - ok
> Data: -4 ---
> System: ---
> Float: --- ok
> [1]FORTH> . -4 ok
> FORTH> pi ok
> Data: ---
> System: ---
> Float: 3.1415926535897932385 --- ok
> {1}FORTH> 2e f* ok
> Data: ---
> System: ---
> Float: 6.2831853071795864770 --- ok
> {1}FORTH> f. 6.283185 ok
>
> Like this?

If you've patched the system such that it automatically displays stack content,
then well and good. I would suggest there's nothing to be gained displaying
stacks that are empty.

On 11/04/2022 20:26, albert wrote:
> In article <t2v8f0$1h8t$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
>>On 10/04/2022 04:32, Paul Rubin wrote:
>>> S Jack <sdwjack69@gmail.com> writes:
>>>> In Fig days and before Linux it was common and convenient to hit dot
>>>> twice for an illegal command to clear the stack. That quickly evolved
>>>> to the word ".." that would clear the stack without an error message.
>>>
>>> In gforth (and maybe it is in ANS) "clearstack" clears the stack, and I
>>> usually alias it to "cs" when testing stuff.
>>
>>ABORT clears the stack without an error msg. Error msg or not I'm puzzled
>>why another word is necessary. It's a rare app that needs it and trivial
>>enough to define when one does.
>
> You must be kidding. Teach a Forth novice to clear the stack by invoking
> a scary word like ABORT ? .

Novices have never tried to type in a word that doesn't exist? They must
be well trained :)

> Better declare ABORT obsolescent because
> it lacks clear intent, and the suggestion that it may be equivalent
> to a throw makes my head spin.

ABORT is useful for getting back to a clean state which includes emptying
the stacks; whereas QUIT is useful for debugging because it doesn't empty
the stacks. In my system there's a further distinction:

Like ABORT, QUIT may be used to terminate an application at any
nesting level. Unlike ABORT, QUIT in DX-Forth is not considered
an error condition and cannot be intercepted with CATCH.
> Also ABORT doesn't work in a definition to clear the stack.

It doesn't just clear the stack if that's what you mean. Anyone that chooses
'clearstack' for the name of a function which just clears the stack, clearly
never intended it to get much use. Which aligns with my experience. Novices
are welcome to knock themselves out using it.

On Saturday, April 9, 2022 at 6:25:20 AM UTC+2, dxforth wrote:
> I recently began using a forth which did a .S (among other things) in QUIT.
> I previously considered such too verbose but have to say it's grown on me
> after intensive debugging involving spurious values on the stack. Some
> forths simply display DEPTH if non-zero which is akin to this teaser:
>
> "I've just picked up a fault in the AE35 unit. It's going to go 100% failure
> in 72 hours."
>
> No worries, Forth. I think I'll just ignore it :)
>
> Curious to know other forthers experiences/preferences?
Well, given that 4tH has a completely different architecture:

- When I'm testing stuff, I'm always adding either "DEPTH ." or ".S".
The former is a "builtin", so when I remove the "TOOLS" lib, I won't get
a compilation error;
- When writing serious application software (like in professional enviroments)
I'm almost always adding a check on "DEPTH" before leaving. If something is
left, it can have serious repercussions - so I wanna know. For end users, it's called
"system integrity" or "memory leak" - but that's not important right now;
- ABORT is the "get out of here!" command. It can't be caught. If you wanna
catch it, in 4tH you have to throw something. Hence, there is a THROW" as well.

In Gforth, there is now a small indication on what's left on the stack. In its current
form, it doesn't bother me too much. So far, it hasn't been really helpful either, but
that might change with one single occurrence. I do mostly porting work on Gforth,
so when something is wrong, it's usually in the differences between Gforth and
4tH.

When debugging 4tH, yes ".S" is my most intimate and most loyal friend. I only
see him when I invoke him, since 4tH does not have a prompt. But I would think
that even a friend like ".S" would become a nuisance if he dropped by uninvited.
For that, I'd prefer the presence of "DEPTH", I think.

Hans Bezemer

the.bee...@gmail.com schrieb am Dienstag, 12. April 2022 um 15:43:24 UTC+2:
> On Saturday, April 9, 2022 at 6:25:20 AM UTC+2, dxforth wrote:
> > I recently began using a forth which did a .S (among other things) in QUIT.
> > I previously considered such too verbose but have to say it's grown on me
> > after intensive debugging involving spurious values on the stack. Some
> > forths simply display DEPTH if non-zero which is akin to this teaser:
> >
> > "I've just picked up a fault in the AE35 unit. It's going to go 100% failure
> > in 72 hours."
> >
> > No worries, Forth. I think I'll just ignore it :)
> >
> > Curious to know other forthers experiences/preferences?
> Well, given that 4tH has a completely different architecture:
>
> - When I'm testing stuff, I'm always adding either "DEPTH ." or ".S".
> The former is a "builtin", so when I remove the "TOOLS" lib, I won't get
> a compilation error;
> - When writing serious application software (like in professional enviroments)
> I'm almost always adding a check on "DEPTH" before leaving. If something is
> left, it can have serious repercussions - so I wanna know. For end users, it's called
> "system integrity" or "memory leak" - but that's not important right now;
> - ABORT is the "get out of here!" command. It can't be caught. If you wanna
> catch it, in 4tH you have to throw something. Hence, there is a THROW" as well.
>
> In Gforth, there is now a small indication on what's left on the stack. In its current
> form, it doesn't bother me too much. So far, it hasn't been really helpful either, but
> that might change with one single occurrence. I do mostly porting work on Gforth,
> so when something is wrong, it's usually in the differences between Gforth and
> 4tH.
>
> When debugging 4tH, yes ".S" is my most intimate and most loyal friend. I only
> see him when I invoke him, since 4tH does not have a prompt. But I would think
> that even a friend like ".S" would become a nuisance if he dropped by uninvited.
> For that, I'd prefer the presence of "DEPTH", I think.

A DEBUG word comes in handy now and then. Here on a stupid word:

# : test 1 2 0 / rot ; ok
# test
? test
^ ?? division by zero
Stacks: r: $0 | 1 2 0 --
Backtrace: / <- test:7
# debug test ok
# test
$4482D0: deb# _[LIT] 1
$4482E0: 1 deb# _[LIT] 2
$4482F0: 1 2 deb# _[LIT] 0
$448300: 1 2 0 deb# /
? test
^ ?? division by zero
Stacks: r: $0 | 1 2 0 --
Backtrace: / <- test:7
#

On 12/04/2022 23:43, Hans Bezemer wrote:
>
> When debugging 4tH, yes ".S" is my most intimate and most loyal friend. I only
> see him when I invoke him, since 4tH does not have a prompt. But I would think
> that even a friend like ".S" would become a nuisance if he dropped by uninvited.
> For that, I'd prefer the presence of "DEPTH", I think.

I think Marcel's .S would quickly become a nuisance :) 'depth' is no real
replacement for .S Instead of a 'depth' that's a cut-down .S just cut-down
on what .S shows. What this discussion has got me to consider is perhaps
I need to cut-down on some of the verbosity my aborts currently display e.g.
do I need to display "Error:" when it so blatantly is. We can all do with
less clutter :)