Re: connecting

On Thu, 3 Mar 2005, Dr Nick Maroudas wrote:

>>>> Now Nick here:
>>>> Mark,
>>          Terry (above) has given you his online reference, and
>> outlined the way that Forth's mechanism for compiling and searching a
>> dictionary (subdivided into specialized vocabularies if necessary)
>> might be inherently suitable for programming data retrieval.  My two
>> contributions stressed the primacy of temporal order and sketched
>> out what your socalled "active" program might actually do:  namely,
>> to compile a temporal pile of incoming documents into a small Forth
>> dictionary of linked words.  The pile is maintained whole & intact
>> (read only); if you like, you can plough thru it from start to finish
>> with a conventional linear search.  The "active" Forth program should
>> be faster, because it would search only those documents whose dates
>> are found in Forth definitions of the words that you want.
>>
>>  I do not know any online reference, because I learned Fig back in
>> the book age, but it was then common practice to search a compiled
>> dictionary for a name (use -FIND & ID.) to SCAN a compiled definition
>> into its component words, and thus to extract a specific WORDLINK.
>> Now that CF has done away with working on compiled object code
>> ("Source is all there is") it ought to be even easier.  All you have
>> to do :) is to write a program that reads the incoming stream and
>> translates interesting words into blocks of source :)  Even translate
>> those CF blocks into ASCII to search with an ordinary word processor.

I have an idea, maybe it is related. Chuck has talked about FML and a new 
type word that is executed at display time. So FML is essentially 
colorForth source. The email header and body could be parsed and stored as 
an FML document. At display time the display time words would be executed 
yeilding a properly formated email. The same concept could be applied to 
web pages, jpeg images, what ever else. The extra information I've talked 
about previously like sender, subject, is effectively stored in FML 
source with the addition of the display time words.

I think the simplest possible organization, is simply to have two sections 
of blocks. A system set of blocks which contains all programs, the kernel, 
ect. This system set of blocks is loaded into ram at boot and remains. The 
second section of blocks is all user data, and extends from the system 
section to the end of the disk. FML documents are layed out end to end on 
block boundries. The user interface at this point is simply scrolling, 
just like source blocks. Data blocks are loaded as needed.

At some point in the future, the system is extended with search and views 
which organize the data effectively. As you say, you could simply "plough 
thru it", with a linear search. But to make the search and views fast, 
indicies of the data will be maintained in ram, just like search engines 
have done. I have a feeling text search will take some time to get right, 
so perhaps this will come later once the basic functionality is complete.

Mark