Re: [colorforth] How is colorForth different from other Forths?

["Samuel A. Falvo II" <kc5tja@xxxxxxxx>]

On Tuesday 16 December 2003 01:59 pm, Roman Pavlyuk \(personal\) wrote:
> 1) IF, -IF are written in cf, while THEN is in assembly (color.asm).
> It's because THEN modifies LIST variable (look-back optimizer stopper,
> as I understand it, though cf optimizer requires a separate chapter in
> the specifications), and this variable is not accessible from cf code,
> so you cannot write your own branch construct like that.

My FS/Forth target compiler exposes these variables (both the current and 
previous operation pointers).

> To summarize, I'd like to see a standard, describing what is included,
> why, what is not included, why, how to use what is included, why not
> to use what was not included :)

I think such a document would be quite useful.  But I wouldn't say it's 
essential.  The reason is that it effectively crystalizes the CF 
language into a distinct standard.  E.g., PygmyForth is based on 
cmForth, FS/Forth is based on (but independent of) both PygmyForth and 
ColorForth, etc.  My vision of my Forth is out of date with modern 
cmColorForth.  Chuck would instantly label my Forth as "obsolete" purely 
because it stores program source in ASCII format, instead of a tokenized 
format.  Plus, it's a "classical" Forth in that it uses normal, 
Forth-like punctuation to indicate syntax.  Nonetheless, it fills a 
distinct niche I have yet to be seen filled by any other Forth -- a 
Forth as easy to use as Pygmy Forth under Linux, able to build static 
executables without a lick of hassles.

(I'm pleased to announce that FS/Forth's target compiler now builds a 
fully self-sufficient ELF executable!  It currently lacks the word 
lists, but those are very easy to add.  Trivial, in fact.  I haven't 
done it yet because I haven't needed it yet.  Besides, they're not 
needed for "stand-alone" applications anyway.)

> One more reason why I would not like to focus on comparing cf and
> "other" forths is that I would not like to see cf crystallized in it's
> present state. Does everyone thinks that it's in the best shape and

Any documentation on cf does this what-so-ever.  Of course, standards 
aren't necessarily a bad thing.  They've enabled a whole economy to grow 
and thrive.  If documentation on ColorForth is important to you, you 
have to realize that such material is *dated,* and that the "standard" 
is itself a moving target.

This is why ANSI Forth is considered bad by so many people: it provides a 
great deal of implementation flexibility and innovation, but the 
*language* *itself* is frozen in time; it's basically Forth-83 revised 
to support 32-bit architectures and greater platform independence.  And 
that's great if that's all you want from Forth.  I have no problems with 
refering to it as Forth-92 to commemorate this philosophy.

> Anyway, as to me, in present state it's not a development platform, it
> requires more cleanup and documenting, though I find the environment
> very nice and well thought for the tasks it was designed for.

I think this is the critical mistake that many trip themselves up on.  
The answer to their questions about its lack of viability are answered 
in their own thoughts, "It's great for what it's designed for, but not 
for what I want."  Well, clearly, Chuck had different motivations for 
ColorForth than you do for your ideal environment.

The point to ColorForth was NOT to be a whole, new, all-inclusive 
integrated development environment.  ColorForth was designed for two 
things first and foremost: OKAD-II and the exploration of MachineForth 
on x86.  Within those contexts, ColorForth has been a great success.  
Outside of those contexts, it's often said to have failed miserably.  
(Though Chuck can argue against that point, having authored networking 
software and several useful applets for Forth.)

I'd like to point out that FS/Forth, my own Forth environment (still 
under development), is itself built for one person: me.  If anybody else 
finds it useful, that's icing on the cake.  What is important is not the 
langauge, but the lessons learned from the language.  I learned a LOT 
from ColorForth and watching the MachineForth videos by Jeff Fox.  I 
applied what I learned towards FS/Forth.  I'm really liking what I have 
done so far.  But after showing several people how I write code in 
FS/Forth, they are immediately turned off.  "It'll never amount to 
anything useful," is a rather common response.  "Sure," I respond, "but 
it's useful to me.  And that's what counts."

To those who truely want to understand Forth, I'm sure someone will learn 
a few tricks from FS/Forth, and apply it towards their Forth 
environment.  What is important in the Forth community is not source 
code, but the ideas expressed therein.  For a language with zero 
abstraction built in, it provides the highest level of abstraction of 
any language I've ever seen.  How cool is that?

--
Samuel A. Falvo II


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com