home .. forth .. colorforth mail list archive ..

[ColorForth] Philosophy (part 3 of 3)

Continuing,

To discuss these concepts I've had to come up with a new term.
After all I consider Flux, Aha, ColorForth, and Terry Loveall's code as variations on a theme. They are explorations in pre-processed forth code. They speed up and simplify the compiler by doing some of its work in the editor. They each identify the tokens of code ahead of compile time.
So I call them coloured forths. (Canadian/British spelling of colour and lower case to avoid confusion. And yes, I am Canadian) 

And I'm slowly becoming more and more inspired to write my own coloured forth.

Though my assumptions are different than Charles' or Jeff's.
If I start writing one it wouldn't be a stand alone system. I'm making a few assumptions about the system. Though they'll probably change here is the current list. 

1) First it would be a language that would cohabitate on an existing OS.
Linux, Windows, or both. And I know that would instantly make it more complicated and convoluted.
Don't think I'm too crazy, but the inner core might be written in C. Since it would have to invoke other code and libraries on the OS, writing the core in C makes the most sense. When writing code for an OS written in C, start by writing in C.
Standard C would also make the system more portable even if it would be slower. I use more than one OS and more than one system. Why not write a system to run on as many as possible.
2) Secondly it would not be a coloured forth written on top of a forth. The opposite would happen. I'd write the coloured forth first and possibly extend it to be a non-coloured forth.
My understanding of Aha is that it is a compiler written on top of a non-coloured forth for the F21. I'd be tempted to do things in the opposite order. 

3) Thirdly the editor would come later.
At first I'd write two programs. The initial coloured forth and a program that would translate text based source files into pre-processed forth code to be run by the coloured forth.
My initial editor wouldn't be part of the system. It would be an external program. Since I'm going to run on an existing system (Linux or Windows or both) I want to use the tools I already know intimately. Editors, version control systems, etc... this means I'd start with text based source code.
The 'source compiler' could be written in any language to begin with. It could take a coloured forth file (.cf ?) and end up with a pre-processed file ready to be loaded and compiled in the coloured forth (.ocf ?)
4) Fourth it would start minimal but build up in levels. Why not add a standard forth compiler on top? Why not load and run non-preprocessed text file or block file based forth code? Written in coloured forth of course. Jeff's example of bootstrapping a ANS forth on top of a minimal forth core is very doable.
Implementing machine forth, ColorForth, ANS Forth, and Aha on the same core is simple. Just have them as dialects or wordlists. Want to use ANS constructs then use the appropriate word list. Want IF to behave as in ColorForth, just select the word list. Which ones you include simply depends on which files you load on top of the minimal core.
With preprocessed source code you compile the parts of the language you need as you go. You could also set dependencies between the files of code. The ANS core code might need the machine forth files loaded as well as the minimal core. An editor or programming system could keep track of these dependencies and make sure the correct pieces are ready to load.
This could lead to the illusive method of sharing coloured forth code. With some dependencies in place a central repository of code modules (files) could be built. CPAN for forth anyone?
Of course its easier to share code if the code exists on a multi purpose OS as files. Allows one to use pre-existing tools. I can email you a file so far I can't do that from a coloured forth. This may be the main reason I'm tempted to create a non-stand alone coloured forth. 

5) Fifth I'd add a new understanding and implementation of forth words.
The BMP example is what I'm talking about. I don't want it precompiled. I need to load the code into memory ready to invoke at a moments notice.
I don't necessarily want to have a block based system. Since I want to create multiple programs using this language I can't be stuck with block numbers. It makes it hard to import and combine different code files.
My thinking is to create a new type of word and a new type of load instruction. (Don't Laugh, it would be transparent.)
Take the BMP example... instead of loading and compiling it I'd do something else. The compiler could realize that the BMP code provides a BMP word. It would allocate some memory, load the code into that space, and create a new word in the current wordlist, BMP. The word would be code to invoke the compiler/interpreter to run the code in the BMP memory space.
You would think you're just running another compiled word, but you'd be invoking the compiler/interpreter to work its way through preloaded code. All the simplicity of a word that's ready to run and all the power of a chunk of coloured forth ready to be compiled and interpreted. I'm not sure, but it seems to be the best of both worlds.
Large programs could then be built from smaller chunks. Take the chunks of code you wish to use, with all dependencies handled, and build one large pre-processed file. This could be done in an editor or with standard MAKE type tools.
When run, the core would load the large file. Compiling, loading code into memory, and doing work as necessary. After the file was read you'd end up with a running program. Parts that need to be compiled would exist as standard compiled forth words. Code that needed to be loaded into memory to be compiled/interpreted later would be loaded and turned into words ready to be invoked as the code needed them. This is my version of Jeff's Aha idea of code chunks in ROM ready to be compiled/interpreted as needed. 

Sound practical? I'm not 100% sure... but its starting to sound right.
6) Sixth, and not least there would have to be an editor written at some time. The continuing essence of forth, even in coloured forths, is the ability to compile and interpret from a running system. With a coloured forth an editor that can preprocess the code is essential. The point should be to build a system that could keep building its own components in the standard forth way. Interactively.
As well the editor would probably be a 'decompiler' or a 'deprocessor' as well. The built in editor would work directly on preprocessed code. Just as the ColorForth or the Flux editor does. It would also be capable of exporting the code as text files. To borrow the file extensions I used earlier, the editor would work on .ocf files but also export the .cf text files. This way text based version control tools would still be available.
Of course the editor would be capable of loading either. If it was preprocessed it would be loaded and edited. If it was a text file the editor would properly preprocess it and then edit it.
I don't know if this system I'm dreaming up will ever see the light of day. I'm still forming the ideas that might lead to it. But that's what I've got so far.
I hope I haven't been too long winded, but that's where my thought process has been going. That's what I've learned so far from ColorForth, Aha, and Flux. 

Any comments or suggestions?

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