Re: [colorforth] Test 5 am i getting thru

["Jeff Fox" <fox@xxxxxxxxxxxxxxxxxxx>]

> I understand that Colorforth has several words to search the dictionayr.
> One for colon works and one for values or variables what ever they are.

Yes, they key thing is that those are editor functions:

def name
 searches the source for places where "name" is defined in red
find name
 searches the source for places where "name" is used

the f key in the editor repeats the last find

> Can any one expond on this and dell me if we can do it in F83s or
> Win32Forth?

The complication is that those things are editor functions in
colorforth while the functions that are sort of equivalent in
traditional Forth are usually related to the forth dictionary
searches and thus related to the Forth compiler.

When you 'find' a word in traditional Forth you are finding
the last occurance in the dictionary, after compilation.  You are
finding the last place in the dictionary where the word "name"
was defined.

In some systems you can 'locate' the places in the compiled code
where "name" was used and you can be taken in the editor to the
source file to the place there the source did the compilation.

But in neither case are you searching the entirety of the source
code on your PC for all the places where ": name" is used or
wherever "name" appears in active Forth code.  By that I mean
that colorforth will not find "name" when it appears as a comment
but it will find every single occurance of "name" in all source
that could possibly be compiled or executed.

To do the same thing in win32forth you would have to search
the entire hard disk, search the whole disk for the string
"name"  then you have to figure out if it was in the context
of being compiled, which is a non-trivial task.  If "name"
occurs between a ": namedef" and a ";" but not if preceeded
by a "\" on the same line, or not in a block preceeded by
a "0 [if]" or anything that works out to be the equivalent
of commented out code you would do what colorforth is doing.
And that would nearly impossible because, for instance, the
calculation of what logical value might precced a [if] in
the source file, or the relationship between what file loads
what file, requires, depends, maybe, possibly, type words
controlling compiling knowing what really is potentially
compilable code on your hard disk is virtually impossible.

On the other hand in colorforth Chuck designates what part
of the disk holds source code.  He copies that to RAM at
boot. He searches the entire source on the computer and
because the source is pre-parsed and has colortokens designating
whether a word is being defined for being used it is easy to
almost instantly search all of the source on your computer
and have already tagged every place where "name" is used as
the name of a definition or where "name" is used in Forth source
as something other than a comment.

If I run generic colorforth on my machine doing one of these
searches means searching about 64K of ram for places where
"name" is in the color you want.  If I run it on colorforth with
okad2 loaded there is more source code loaded into the system.
The system has to search 530K of RAM for places where "name" is
in the color that you want.

If I run the same sort of thing in a win32forth environment on
my machine I would have to search all the .f .4th. .fth, .src
etc. files that might contain Forth source.  Unlike colorforth
all the source on the machine is not already in RAM so I would
have to search a drive using the file system.

So in one case I am searching a few K of linear RAM for pre-parsed
data that is easy to identify.  In the other case there are gigabytes
of disk space to be searched through file structures for files, then
the files have to searched, and finally one would have to figure
out if an occurance of the string "name" was potentially compilable
or executable Forth that was not somehow commented out or unreachable.

I suppose if your compiler created log files that could be searched
it would make it possible to search a sea of source files that you
had compiled and find every place where "name" was actually compiled,
execued, postponed, or parsed.  But you wouldn't be searching all
the source on the machine, and you couldn't search it with your
editor until after you had compiled it and generated these cross
reference log files.

In colorforth the editor marks every occurance of "name" in the
source with how it is used and whether it is compiled or executed
or defered or just a comment.  It is not a compiler function.  It is
and editor function.

Colorforth searches all the Forth source almost instantly
in a simple way, while in ASCII source file based Forth system
the equivalent would be to search for files on a drive, search
the files, and then face the nearly unsolvable problem of
second guessing what a compiler is going to do with the source.
Otherwise there would be now way of knowing if "name" was
being defined, being compiled, being executed, being defered,
being parsed, appearing as a comment, or appearing in a string,
or appearing in a commented out section of otherwise valid code.

What Chuck is doing is having colorforth decide what on the
disk is Forth source, and the editor decide what are comments
and what is code, and he has it RAM ready to be searched by
the editor.  In a file based Forth it is hard to determine exactly
what might be Forth source files on your disk.  Then it is hard
for an editor to determine what ASCII names are really code
or comments.  Instead of a few K of source blocks in RAM in
colorforth you have a variable amount of disk space to search
in a file based system.  Most importantly an editor knows how the
words are to be used in colorforth and that isn't usually true
with ASCII file based soure format environments.



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