I finally isolated my random crashes due to the way my Forth was seeing where a colon definition was being defined in relation to where the data stack was.

In other words, if something was on the data stack before a colon definition was being defined, under certain circumstances would cause a crash due to the data stack stack not being empty.

I can work around this but is there any reason anyone can think of why the data stack should not be cleared before defining a new colon definition?

Any values that were there can just as easily be re-calculated or added after the new word is defined.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

The basic problem is having something on the stack is hindering the way I would like to program. Which is to prevent errors from popping up. Funny enough, once an error happens the stack is reset and I don't have a problem for a little while.

I understand the compiler security check, and I see what it is doing to match definitions.

I can see how having a headerless (or invisible) definition might be of use. It could reduce the number of dictionary entries, keeping it from being so cluttered and having to create a new word.

The one nice thing about Forth is that I can have my cake and eat it too. Creating another colon definition that resets the stack before calling the original colon definition fixes a lot of my woes.

Speaking of invisible, I found a way to make a header invisible and visible again. The smudge bit doesn't make the word invisible to the dictionary Lister.

To hide a word, the status byte of a word is set to xx000000, preserving the x-bits, and will prevent TYPE from typing a word out during a dictionary LIST operation. TYPE has ?DUP IF ... ELSE DROP THEN ; added to it to handle null length words.

To unhide a word, I wrote a word that finds NULL length words and tries to match to the word to unhide and resets the length count of the word. Another word definition lists all words that have no length.

Garth mentioned an example, and a related example is defeating Complier Security, as sometimes becomes reasonable. And I'm sure other cases could arise where clearing the data stack could create limitations.

Clearing the data stack would violate the "Mind Your Own Business" principle. IMO the process of creating a new colon definition should just do its job, ignoring the (irrelevant) presence or absence of other items already on stack.

I'm unclear on why having something on the stack would hinder the way you'd like to program, so maybe we can talk more about that. Clearing the data stack seems like an uncalled-for workaround.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I think I found the reason for the the random crashes.

The input routine used in EXPECT calls a ROM routine that does a nice job for line input, which for the most part, suits Forth quite nicely. The ROM routine also has a cancel-input option using CTRL-X that returns an input length of zero. The author of this Forth forgot to handle the case where the length of the input is zero, but the EXPECT code still continues on storing some bytes in unauthorized places.

Handling that exception has made everything a lot more stable. All is well now, I hope.