fig-FORTH EXECUTE

[GARTHWILSON]

Good point! I guess I did it that way just because the '02 Forth I had come from did it that way. And why did they? Maybe they separated it out for debugging, or maybe just because someone told them definitions shouldn't be so long, or maybe they had something else in mind that I haven't come across. I looked at several other Forths I have books on, and nobody else separated them out like that. I guess I could integrate mine and save a little memory. Thanks.

[BruceRMcF]

IamRob wrote:

OOC, where else would either INTERPRETER or COMPILER be used outside of INTERPRET that would require them to have their own definitions?

Personally I like the all-in-one combination of all three in Fig Forth.

For INTERPRETER one use case might be if the user wanted to set up a vocabulary of words to be used in an application (eg, a menu system) that are all interpreted.

But, yes, factoring eases testing and debugging as you are building a wordset, which is why many advise that most definitions should be two to seven words long. The shorter the word, the easier it is to identify and test all edge cases before moving on to the word that contains it.

In that example, a peephole optimizer could be added to the COMPILER word, without having to test whether a regression was introduced for the interpreter state.

[GARTHWILSON]

BruceRMcF wrote:

For INTERPRETER one use case might be if the user wanted to set up a vocabulary of words to be used in an application (eg, a menu system) that are all interpreted.

Interesting idea. Have you seen any examples?

Quote:

But, yes, factoring eases testing and debugging as you are building a wordset, which is why many advise that most definitions should be two to seven words long. The shorter the word, the easier it is to identify and test all edge cases before moving on to the word that contains it.

It could be integrated after being proven working though. Regarding these assertions that words should be so short, one problem I have is simply coming up with meaningful names that aren't just as long as the definition, or even longer. Another of course is the memory the extra headers take up, especially with the names being that long. Another is of course the performance hit because of the many additional occurrences of nest and unnest (which also may be hard on the return-stack space).

[IamRob]

BruceRMcF wrote:

IamRob wrote:

OOC, where else would either INTERPRETER or COMPILER be used outside of INTERPRET that would require them to have their own definitions?

Personally I like the all-in-one combination of all three in Fig Forth.

For INTERPRETER one use case might be if the user wanted to set up a vocabulary of words to be used in an application (eg, a menu system) that are all interpreted.

But, yes, factoring eases testing and debugging as you are building a wordset, which is why many advise that most definitions should be two to seven words long. The shorter the word, the easier it is to identify and test all edge cases before moving on to the word that contains it.

In that example, a peephole optimizer could be added to the COMPILER word, without having to test whether a regression was introduced for the interpreter state.

That sounds a lot like what CASE does. And it sounds like the menu words are being created "on-the-fly", so to speak. Wouldn't it be more efficient to compile all words before the application even starts? Or are we theorizing more to use these words as a sort of program overlay for computers with less memory?

Or maybe something more like importing Pascals Procedure calls.

[BruceRMcF]

IamRob wrote:

BruceRMcF wrote:

IamRob wrote:

OOC, where else would either INTERPRETER or COMPILER be used outside of INTERPRET that would require them to have their own definitions?

Personally I like the all-in-one combination of all three in Fig Forth.

For INTERPRETER one use case might be if the user wanted to set up a vocabulary of words to be used in an application (eg, a menu system) that are all interpreted.

But, yes, factoring eases testing and debugging as you are building a wordset, which is why many advise that most definitions should be two to seven words long. The shorter the word, the easier it is to identify and test all edge cases before moving on to the word that contains it.

In that example, a peephole optimizer could be added to the COMPILER word, without having to test whether a regression was introduced for the interpreter state.

That sounds a lot like what CASE does. And it sounds like the menu words are being created "on-the-fly", so to speak. Wouldn't it be more efficient to compile all words before the application even starts? Or are we theorizing more to use these words as a sort of program overlay for computers with less memory?

Not on the fly, but independent of the menu system, so the menu can be tailored to the use. One variable to hold the main menu word vocabulary, and a block or file with the menu structure... first word in a line is the main menu heading, following words are choices within that heading. You can develop with a typed command dispatch to test words, and when you have the actions you want in the menu, type up the menu structure.