[ColorForth] Passing values from Compiletime to Runtime

["t" <loveall@xxxxxxxxx>]

Dirk,

Here is the high level definition in quasi-ANSI forth for the interpreter
from the ColorMan.txt doc file:

BEGIN                     ( get input and interpret loop)
  QUERY TIB @ >IN !       (   get user input, reset text pointer)
  BEGIN                   (   start interpreter loop)
    SP@ SP0 @ <           (     test for stack underflow)
    IF STAKERR THEN       (     execute stakerr if true)
    TOKEN DUP             (     delimit next input word)
  WHILE                   (   while not end of line which is a 0 length
token)
    FIND                  (     search dictionary)
    0= IF ABORT THEN      (     if not found then abort on bad word)
    DROP @EXECUTE         (     execute, otherwise)
  REPEAT                  (   continue interpreter loop)
  2DROP                   (   0 length token)
  .  " OK" CR             (   make user feel good)
REPEAT                    ( forever)

<red>1+<ltblue>1<purple><green>+<black>;
(These are the correct colors from 4word).

All it does is delimit strings and look them up in the dictionary, period.

<red> says delimit the next string and create a dictionary entry.

Numbers are valid numeric strings prefixed with a color that says the next
string is a number. Delimit and convert per the (ltblue for hex) specified
number base.

Then a number can be post-fixed by a different color (purple) to say 'take
the number on top of the parameter stack and compile it inline'.

This is where the double colors come in. If 'compiling' you have the 'inline
literal' color followed by the 'delimit the next string, find in dictionary
and compile' color (green).

Finally, ';' is in normal forth terms an 'IMMEDIATE' definition which
implicitly interprets the word. 4word ColorForth says why be implicit?
Prefixing ';' with black says intrepret the next word. No need for
'IMMEDIATE' and I understand what the compiler is doing. BTW tail recursion
in 4word is _explicitly_ invoked with the definition ';;'.

Regards,
Terry

----- Original Message -----
From: "Dirk Heise" <dheise@xxxxxxxxxxx>
To: "ColorForth List Member" <ColorForth@xxxxxxxxxxxxxxxxxx>
Sent: Wednesday, May 02, 2001 8:56 PM
Subject: [ColorForth] Passing values from Compiletime to Runtime


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

------------------------

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