[ColorForth] Philosophy (part 1 of 3)

[David Govoni <dgovoni@xxxxxxxxxxxx>]

To all,

With all this talk recently of philosophy and our various reasons for being 
part of this list I thought I'd switch from lurking to weighing in.

And with the tradition on this list for reasonably long posts, I hope 
nobody will be offended if I write a bit. (I'm breaking this up into parts 
to make it easier). Forgive its rough nature, but this is the first time 
I've coalesced some of my ideas into one place.

A bit of background. When it comes to computer languages I'm an omnivore. I 
consume all I can find. I've never been a purist who insists there is only 
one true way. From experience I've learned that borrowing ideas and 
techniques between languages is much more useful than strict adherence to 
any one language. Part of being a consumer of as many languages and 
techniques as possible is the desire to follow those who take languages and 
ideas to new levels. And that's how my interest in Forth became more of an 
interest in ColorForth and related projects such as Enth and Flux, Aha, and 
Terry Loveall's explorations in 1x programming.

First I found that Charles' and Jeff's evolution into chip specific forths 
interesting. When you're designing a chip and a language at the same time 
the chip evolves to support the language and the language evolves to 
support the chip.

Forth never needed the idea of an address register with an autoincrement 
store command. But if you're designing an chip level language it makes 
perfect sense. Cutting the number of fundamental op-codes makes sense if 
you're building a minimalist chip.

One of the most profound things I found was Jeff's ability to make a 
roughly ANS standard forth from a minimalist forth in only a tiny amount of 
code. Most forths seem to be built around a core that self-extends to the 
base language. But not many can provide an ANS style forth in so little 
code. machine forth and its offshoots show how efficient and powerful a 
well designed minimalist language can be.

And then came ColorForth and some of Charles' ideas.

Forth is known as having an incredibly simple compiler. Its hard to imagine 
a compiler that's much simpler. Then I came face to face with ColorForth. 
Charles breakdown of where time is spent has been central to much of my 
thinking.

0) Programmer Time (removing code completely by not coding it)
1) Edit Time (pre-processing code to make compiling faster)
2) Compile Time (remove references and variables and hard code values)
3) Run Time (do work that can only be done here)

The earlier work can be done the less time is spent further down the 
process. If you preprocess forth source code you can simplify and speed up 
the compiler.

If the compiler doesn't need to recognize literals, or words, or variables, 
or comments, or strings then it can be faster. Why check if a token word 
exists before checking if the token is a number? Why not have the 
programmer and/or the editor mark the token as a constant. Taking it 
further, mark the token as a constant and store it as a binary value for 
faster compiling (which is what Aha does in my understanding).

The idea of compiling routines as you need them makes more sense when you 
have an incredibly simple and fast compiler.

Most language compilers are complex and time consuming. Step 2, compile 
time, has to be accomplished well before the user is exposed to the 
program. Several open source programs I use can take 15 minutes to compile. 
There is no way to have this happen when the user wants to run the program.

So the program is compiled and stored so it can be loaded as a binary when 
the user wants to invoke it. Therefore there is no way those programs can 
take advantage of compiling routine specific code at run time. (This may 
also be why many large programs include an internal interpreted scripting 
language. There is no practical way to extend the program in its own 
language. A C++ program is hard if not impossible to extend on the fly, but 
a macro language allows the user to add to it.)

So why are programs so big and complicated? I'm not sure, but I have two ideas.

(end of part 1)

David Govoni

------------------------

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