[colorforth] colorforth code in ASCII

["t" <loveall@xxxxxxxxx>]

From: "Kurt B. Kaiser" <kbk@xxxxxxxxx>
> > See "Color Forth" section of
> > http://www.users.qwest.net/~loveall/binary/concluse.txt
> > for a more detailed operational description.
>
> This is a very interesting document.  Thanks for the insight.  Is it
> linked from your home page?

This is the informal conclusions I came to after putting together a study in
five color forths. That URL is linked from
http://www.users.qwest.net/~loveall/ModProg.htm
and is included as "Forthish\Readme.1st" in the "5 Forths w/source".

<...>
> Being able to switch back and forth from Color display to ASCII
> display, and being able to print and store using ASCII is very
> helpful to the acceptance of ColorForth, IMHO.
>
> Your point about the Forth programmer being one with his code is can
> hardly be overstated.  I am used to reading compiled Forth directly in
> memory (completely understanding the structure of memory and the
> execution model!) during debugging and I think that while headless,
> Huffman encoded, and possibly in-lined code is great for production,
> it should be produced at the end by some kind of optimizer so that the
> code in memory is not obfuscated during development.

Depends on what your priorities are. A seperate dictionary table enables
overlapping code definitions as per Chucks colorForth kernel, at the expense of
managing seperate memory areas.

Mixing the dictionary and code simplifies memory management and encourages
singular function modules for a slightly larger footprint.

I would do the development and final production in the same model to minimize
qualification testing.

> Regards, KBK

Regards,
Terry Loveall
------------------------

To Unsubscribe from this list, send mail to Mdaemon@xxxxxxxxxxxxxxxxxx with:
unsubscribe ColorForth
as the first and only line within the message body
Problems   -   List-Admin@xxxxxxxxxxxxxxxxxx
Main ColorForth site   -   http://www.colorforth.com