[ColorForth] pre-parsed source and code sharing

[Myron Plichota <myron.plichota@xxxxxxxxxxxx>]

I am intrigued by many of the ideas, but neither enamoured with nor
hostile to ColorForth. I am not a user because I disagree with many
of the design decisions. My priorities differ.

Mark Slicker wrote:
> 
> Hello,
> 
> Previously some comments were made that the pre-parsed format of
> colorForth inhibits code sharing. I believe it really improves code
> sharing.
> 

How have tests proved out? It strikes me that the practice of early
binding
coupled with several different versions out there already would restrict
code sharing. Even within the same version isn't it necessary to start
from the boot dictionary, loading blocks in a strict sequence without
any user-defined words intervening?

> Firstly, differences in style are minimized. The character set is minimal,
> so variances in naming style are minimal. Only the first word of a name is
> put in the dictionary. So prefixed names are effectively
> discouraged. There is no white space, so there can be no difference in
> white space conventions. Words are only lower case, so there can be no
> difference in case conventions.
> 

I don't see lack of options as an advantage. Indented code and
mixed-case
naming and commenting make things look "nice" and why not? It's one
thing
to adopt a private character set for a private environment with no
aspirations to go beyond that closed world, but then any credible
discussion
about surfing the Internet and partaking of email, etc., etc. is
precluded.

> The blocks further improve code sharing, shadow blocks provide a standard
> way documenting your code. Blocks also encourage a modular style of
> application development.
> 

I used to write assembly language for early microprocessors with short
in-page
branch instructions and it was OK most of the time but aggravation often
enough to be glad that more amenable architectures became available. I
prefer
to pursue a minimalistic style in an environment the gives me the option
of
extravagance as I see fit. Pages and blocks result in Swiss cheese use
of
mass storage and memory to some degree. BTW, I have yet to see a
_single_
stack diagram in any of the ColorForth code examples so far. Is this
adhering to a "standard way" of documenting Forth code?

> Lastly, the operators of colorForth improve code sharing. Control
> structures like 'if ... then' 'for ... next' 'begin ... end' only allow a
> byte displacement. This forces you factor highley nested code, it also
> improves the ability for someone to read your code.
> 

Impeccably-factored code comes with a price tag: call/return overhead
performance impact, dictionary namespace, and the time spent trying to
come
up with a sensible and unique name for each factor. I often replicate
factors inline when performance is critical. Sometimes I do it when I
fail to recognize the opportunity to factorize the problem further but
wish to move on with the project. When reading someone else's code it
relieves me of having to remember that when I see "baz" it means "foo 
bar blah" if it doesn't appear on the same viewing screen.

> This is all I could think of at the moment, I'm interested in the counter
> argument, for ASCII against pre-parsed.
> 

If the priority is to be different at all costs, gloat over every byte
saved,
cut all ties with the mainstream, and paste stickers on your keyboard,
then
do not on any account consider the use of any standard character set.

Myron Plichota
------------------------

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
Wiki page http://kristopherjohnson.net/wiki/ColorForth
ColorForth index http://www.users.qwest.net/~loveall/c4index.htm