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

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

On Sunday 14 December 2003 08:37 pm, Jeff wrote:
> So, why not just make your fields like above? What happens a month
> after my product is released and I find that field2 needs to be 2
> bytes larger than it is? All other fields suddenly become a mess!
> I could have just altered one word in the code and poof -- all fixed.

Fortunately, such changes are universally localized to just that one 
structure.  Embedding structures inside other structures rarely (ever?) 
poses a problem, because one typically uses a constant to indicate the 
size of a structure:

  : list_head ;
  : list_nullptr 4 + ;
  : list_tail 8 + ;
  : list_SIZEOF 12 ;

> IMHO, this is what a compiler is for. This is what a compiler does. I

A compiler is a program that translates a source text into an output 
text.  Support for structures is not intrinsic in its stated purpose.

> don't mind writing assembly. And for many things, I prefer assembly to
> any other language. However, assembly is terrible for subroutine
> calling, memory management and data structures. In order to create a
> functional program, there must be some order to the above stated.

I must object to this.  I find assembly language to be every bit as good 
as C when accessing structures, performing memory management, and so 
forth.  I spent the better part of my life coding for AmigaOS using 
nothing but assembler because I couldn't afford a C compiler at the 
time.

> Forth is fantastic at the first. The second is typically static,
> which is fine, because the stack handles all dynamic memory that is
> typically needed (and an OS can handle what isn't typical). However,
> the third isn't handled well at all. DOES makes this possible.

Don't forget the compile pointer too -- you are allowed, and even 
encouraged, to use ',' and 'C,' inside your Forth definitions to 
allocate/build data structures at run-time.  Chuck does this 
extensively.  I do it with FS/Forth's target compiler to build ELF 
executable headers.  I'm sure others use similar techniques.  In fact, 
it's such a handy technique that GNU has an 'objstack' library that 
implements this very behavior.

To free memory, you either EMPTY the dictionary, or you ALLOT with a 
negative number.

> To get back to the original question, though :) How can this be done
> in colorForth (talking about how cf and other Forths are different)?
> And if it isn't done, why not? is there another method? is it just not
> used very often? is there a down side?

Chuck already answered all of your questions above.  Please re-read his 
previous post.

I also posted an equivalent to implementing DOES> in ColorForth.  Please 
re-read my previous post.  :)

> very difficult to write in Forth. Once I sat down to actually code it
> in Forth, it was 10x smaller and 100x simpler! Admittedly, though,
> because the process of solving the problem had already been done.

One of the things I value most about both Forth and Lisp (and it's 
cousin, Scheme) is that they both allow for "exploratory programming."  
For example, I'm debugging code in my target compiler's ELF support as 
I'm writing this e-mail.  The code isn't part of my official code base 
yet.  It's a single block of code implementing the ELF ".shstrtab" 
section.  I've narrowed the bug down to a single definition.

Still, once I figure out how to solve this problem, I'll be able to 
certify that the code works as planned, and will include it into my main 
production code.  So even though the problem wasn't pre-solved, the fact 
that everything fits on a single block for me is significant.  I like 
that.  And I have room to spare.

> Creating a document on what makes cf different from other Forths is
> great. But don't focus on color (IMO) and don't focus on blocks of
> code or things that make it "asthetically" different. Focus on what
> makes FORTH powerful, and how colorForth BUILDS on those attributes
> (even if it is by taking away). Color and Huffman coding will end up
> naturally finding their way into the document. But not as a "hey!
> look! we're different and better!" but more as a "this is better...
> how can it be done? with this..."
>
> I sincerely hope I'm not coming across in the wrong light.


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