[ColorForth] Passing values from Compiletime to Runtime

["Dirk Heise" <dheise@xxxxxxxxxxx>]

> Von: t <loveall@xxxxxxxxx>
> An: ColorForth List Member <ColorForth@xxxxxxxxxxxxxxxxxx>
> Betreff: [ColorForth] Passing values from Compiletime to Runtime
> Datum: Donnerstag, 3. Mai 2001 00:10
> This is an implementation that behaves as you describe, i.e.
> "[red] 1+ [green] 1 [grey] + [black] ;"
> using your colors.

Wait, wait... where is the interpreter told to compile a 
literal??? Did it figure out by itself?

> 
> Chuck described using jump tables based upon the current color and
previous
> colors (a context sensitive interpreter/compiler). The implementation of
the
> color sensitive interpreter that I came up with, had seperate
> interpret/compile mode definitions that were more complex and less
obvious
> as to how they operated.

Does this mean each time i write [decimal number] [compile a call].
the interpreter shall silently compile a literal? If so, i
would see this as a non-obvious solution, and it might even 
erode some flexibility needed.

> 
> Later, when implementing 4word, it became apparent that at the cost of
> having back-to-back colors, the interpreter/compiler could be simplified.

I see. That's a good thing - i (and co-programmers at work)
get bitten often enough by C++ compilers that always do
what *they* figure i mean (which is sometimes not what *i*
meant ;-))

> This, I felt, was a worthwhile trade-off. It also forced me to keep in
mind
> the exact cost in additional memory for inline literals. Sometimes memory
is
> more significant than speed, and sometimes the reverse, but exactly what
the
> interpreter is doing is always present.

I consider this the most important point.

> 
> If the readability of the source code becomes significant enough, the
means
> to implement this change are available. However, during the writing of
the
> rest of the code in the 4word package, it never seemed to be a necessity.

Yes, i'm concerned about the readability. Also, it could make 
certain variations codeable (or readable), 
imagine, for instance

  ... do ... loop ...
versus
  10 0 >>do ... loop ...
When ">" means "compile a literal, it would be rather obvious
here that ">>do" is a specialized version of "do" that uses
two constants (i.e. values computed during compiletime).
This could allow optimizations.

[Well, i know that the use of do...loop is not standard
Color Forth, and i really do like the tail recursive
coding, but in certain cases, i would stick back to do...loop
or, my favourite, LOOP...?EXIT...POOL (LOOP and POOL form
an endless loop, ?EXIT can occur multiple times and
exits the loop when top of stack is true), a matter of what
one sees more appropriate]


Dirk
------------------------

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.ultratechnology.com