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

[Jeff <jma@xxxxxxxxx>]

Hello Samuel,

Sunday, December 14, 2003, 10:15:09 PM, you wrote:

SAFI> 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.

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

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

In my experience, such changes are never localized. What if a member
was a byte and now needs to be a word? There is far more work to be
done than simply incrementing some address offsets. Loads, stores,
etc all need to be updated.

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

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

Perhaps just a difference of opinion. But to me, a compiler is far
more than a language "translator". A compiler must have its own
structure that it adheres to: which registers are used for what, how
arguments are passed, where data is stored, etc.

These design decisions are made in all programs, regardless of
language. However, the lower level you get, the more you are a part of
these decisions.

>> 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?

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

Yes. Chuck's post did answer the questions. :)

I can see as I write my posts that my own feelings are coming to light
within myself. DOES is only one part of a bigger question, that
perhaps I'm only now realizing.

The structure problem that we've been tossing back and forth is a
perfect example of what I'm thinking:

Large programs are not written in assembly, because the design and
implementation must be perfect the first time (and excellently
documented). Forth is beautiful because it is only slightly higher
level than assembly and practically documents itself.

"Other Forths" add certain words to their implementation, because
they know the design and implementation will not be perfect the first
time around, and many times the person updating the code is not the
original programmer. Words like DOES and DEFER are very good examples
of this. They allow the system to be expandable and even modify
previously defined behavior.

In many of Chuck and Mr. Fox's writings and speeches that I have read,
I have been humbled by their experience and wisdom I gain. But in the
back of my mind I'm thinking, "this is great! assuming it is done
right the first time..." The structures problem above is trivial.
Simple. But it is still a real-world problem. And I keep coming back
to it not because the answer wasn't given, but that the answer (each
time) has been to hard-code it (check that, Mark's sample was very
nice, indeed).

--
Forever learning,
 Jeff



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