Re: [colorforth] Test 5 am i getting thru

["Jeff Fox" <fox@xxxxxxxxxxxxxxxxxxx>]

Not to get drawn into a block vs file argument
but to clarify;

>> 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.
>
> Well....not necessarily.  Sure if you're a "sloppy"
> programmer that scatters source code all over the
> place.

Most of the file source based Forth that I have worked
with don't have files in one place, although they might be
in subdirectories of one directory.  But things like win32forth
come with source in directory trees and programmers, sloppy
or not, organize their code in further directory trees.

So in one case you are searching a linear section memory
and in the other case you are searching files, opening and
closing files, opening and closing and navigating directories
and making assumptions about things like extension types.  And
the directories are an abstraction that take control of the
physical location of the abstract file away from the programmer.

> But if you only put forth source in a
> particular directory tree than you don't have to
> search the entire hard disk.

A single file, or a single directory could be spread out
with sectors scattered all over an entire disk.  The file
abstraction hides this.  In contrast to searching a short
section of linear memory files means trees of directories,
files, and sectors which may be spread out over an entire
hard disk, or more.

> Technopoint
> Forth has a "find in files" facility that takes
> works this way.

But it rides on a file system that fools some users into
thinking that directory trees are in one physical place, like
a continuous group of blocks in memory.  It really isn't
as simple as searching one linear section of memory, a
search invovles disk access, building and navigating
directory trees, opening and closing files, using file
allocation tables, and dealing with data that might well
be spread out over an entire hard disk.  Putting files
in one 'place' from the abstracted view does not mean
that you are not having to deal with Forth code spread
out over an entire hard disk. Fragmentation happens
at a level below the abstraction where a file is
"one place" and any actual disk search will be below
the user illusion that one dir or one file is one
physical place in memory.  The file system may have
to deal with a single file being spread out over
an entire disk.

> I agree with all of your other points.  Because
> CF is pre-parsed it can take advantage of it's
> "knowledge" of the source code even when searching.
> Nice.

In his fireside chat Chuck mentioned some feature that
he would like to add to the editor that would require
that it call the compiler between keystrokes to give the
editor even more knowledge of what the compiler is going
to do with the source.  I don't remember what editor feature
he mentioned in that context.

Best Wishes



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