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

[Jeff <jma@xxxxxxxxx>]

Hello Mark,

Sunday, December 14, 2003, 8:58:28 PM, you wrote:

MS> On Sun, 14 Dec 2003, Samuel A. Falvo II wrote:

>> On Sunday 14 December 2003 12:36 pm, Jeff wrote:
>> > 0 constant struct
>> >
>> > : field ( n -- n ) dup create , 1+ does @ cells + ;
>> > : end-struct ( n -- ) create , does create @ cells allot ;
>>

MS> Is a structure not simply a contiguous collection of named fields?

MS> : field0   ;
MS> : field1   1 + ;
MS> ...

Yes, but I very much frown upon hard-coding of data sets. For example,
in my example above, I could have various FIELD(s) dictating the size
of the member variable, and as you suggested, load based on that size,
too:

: CVAR ( n -- n+1 ) dup create 1 allot 1+ does @ + c@ ;
: HVAR ( n -- n+2 ) ... ;
: VAR ( n -- n+4 ) ... ;
: DVAR ( n -- n+8 ) ... ;

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.

IMHO, this is what a compiler is for. This is what a compiler does. I
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.

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.

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?

I believe that most people on this mailing list are pro-colorForth, so
many of the obvious questions tend to slip through the cracks.

When I began learning Forth, I wasn't intrigued by the language, but
by what I read that Chuck said about 10x and "this isn't needed" and
there always being "and easier way". And from my experiences with
Forth over the past 3 years have proven these to me. A year ago, I
would consistently write a piece of software in C thinking it would be
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.

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.

-- 
Best regards,
 Jeff                            mailto:jma@xxxxxxxxx



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