RE: [colorforth] Color Forth and ColorForth Conventions
- Subject: RE: [colorforth] Color Forth and ColorForth Conventions
- From: "Howerd Oakford" <howerd.oakford@xxxxxxxxxxxx>
- Date: Mon, 21 Jun 2004 10:38:54 +0100
- Importance: Normal
Hi John,
Coloured conventional Forth and colorForth are very different.
In Win32Forth you could certainly add a colour field to the word's name
header, and this could improve legibility, given an editor that used this
information. This then begs the question of how you specify a word's colour
in the source code. Currently a colour editor such as WinEd determines the
colour of each word from the context - it has to do some of the work
normally done by the compiler, to decide whether a word is immediate,
compiled, interpreted etc.
In colorForth the colour of each token is stored in the bottom 4 bits of the
word's name. The editor displays the names each in their own colour. This is
closer to storing the colour in the source file, rather than the compiled
name header. This is why colorForth requires its own editor.
The colour of each token is specified at edit time by selecting the current
colour. The colour is used by the compiler to decide what to do with each
token, but the colour value is not stored in any compiled code ( such as a
name header ).
In colorForth the state of the system at compile time is entirely defined by
the tokens in the source. In conventional Forth there is a compile/interpret
state, defined by either the variable STATE, or the contents of a deferred
word.
The implications of this change from conventional Forth to colorForth are
profound.
Regards
Howerd 8^)
-----Original Message-----
From: John A. Peters [mailto:japeters@xxxxxxxxxxx]
Sent: 20 June 2004 23:27
To: comp.lang.forth-request@xxxxxxxxxxxxxx
Cc: win32forth@xxxxxxxxxxxxxxx; colorforth@xxxxxxxxxxxxxxxxxx
Subject: [colorforth] Color Forth and ColorForth Conventions
If we were to change the header structure so each word in the dictionary
stored a bite or cell to declare it's color, it might be worth it. Or there
may be some unused space ready to use, according to the map below. Can we
use the 4 unused bites in the BFA? 7 6 5 4 gives us 4 bytes which is 0 thru
15, or 16 numbers, right? Wea re using 15 colors now, so this is enough for
now. When it works well we might switch to a whole cell that could store a
hex number, or better yet a decimal color declaration like CC 00 CC. Then
there would be room for bold and italics sounds, etc.
How does ColorForth store the colors?
\s
\ ---------------------------------------------------------------------
\ Header structure as of May 2003 for Win32Forth
\ ---------------------------------------------------------------------
\
\ [ link field ] -4 +0 LFA
\ +- [ cfa ptr field ] +0 4 CFA-PTR
\ | [ byte flag ] 4 8 BFA
\ | [ count byte ] 5 9 NFA
\ | [ the name letters ] 6 10
\ | [ alignment bytes ] 0 to 3 bytes for name alignment
\ | [ view field ] n+0 VFA <- head-fields, all are
optional
\ | [ file field ] n+4 FFA
\ | [ optimize field ] n+8 OFA
\ |
\ v
\ [ cfa field ] +0 CFA
\ [ body field ] +4 PFA
\
\ BFA: MSB 8 128 IMMEDIATE flag
\ 7 64 unused
\ 6 32 unused
\ 5 16 unused
\ 4 8 unused
\ 3 4 OFA set if OFA is present
\ 2 2 FFA set if VFA is present
\ LSB 1 1 VFA set if VFA is present
\ -------------------------------------------------------
Thank You,
John A. Peters, japeters@xxxxxxxxxxx
Win32Forth applications, specifications and beta testing.
I am a non-programmer, with more ideas than expertise.
---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com
---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com
