[ColorForth] pre-parsed source and code sharing

[Mark Slicker <maslicke@xxxxxxxxxxx>]

On Wed, 24 Jul 2002, Myron Plichota wrote:

> 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?
> 

The different versions that exist are for machine compatability only, no
system changes have been made. The ones with different resolutions do
require changes to the source. What could be done is to make the screen
resolution as variables, then when the source is loaded it can be compiled
for the particular resolution being used. That would eliminate this
incompatability.

No user defined words is assumed. Most applications are stand-alone. In
the case of libraries the library writer and application writer should
work together to optimize the interface between library and
application. In the process any word naming issues should be resolved.

> > 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?

But you have provided a very weak argument for these extras, I say why
include them? I have already provided a so far unchalanged argument for
the advantages of sharing preparsed source.

> 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.
> 

What does the form of your source code takes have to do with the
world wide web, and e-mail?

> > 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?
> 

Stack diagram? In my source I usually put the stack effect of each word in
the shadow block, along with a description of what it does.

colorForth doen't use paging, the dictionary space is purely
linear. Indeed the branches are short, I don't see this as an impediment.

> > 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.
> 

colorForth code is quite well factored in general, yes. What percentage do
you think call/return takes of execution time? I would think the effect
would not be so great. I've written code which I've gone back later to
optimize, I've never tried inlining code to see the effect. I should try
sometime. Most of my large improvemnts come from improved algorithms. I've
not encountered the name problem so much, well factored code seems to
chose it's own names.

> > 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.
> 

I don't think this was ever the priority. See [1] for the design decisions
and trade-offs. What I see is an honest attempt to advance the practice of
programming and system design.

Mark


[1] http://www.colorforth.com/phil.htm
------------------------

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