connecting

On Wed, 2005-03-02 at 21:10, Mark Slicker wrote:

> On Wed, 2 Mar 2005, Dr Nick Maroudas wrote:
> >>> .... Terry ....(suggests that)...
> >> Forth, with a nested vocabulary structure, can provide the basis for
> >> 'attribute typed' data storage. The basic managed 'physical' tree structure is
> >> provided by the vocabulary nesting.
> 
> Then Mark asks: 
> Is there some online reference for the nested Forth vocabulary? I have 
> some trouble understanding the techniques described below, how the search 
> is performed, etc.
> 
> To which On Thu, 2005-03-03 at 00:58, Terry Loveall wrote: 
> Mark,
> The only online reference that I am aware of is the source for 'prok', a
> "minimal 32bit direct threaded subroutine 1x study" that is part of the 
> '5 Forths w/source'. URL:
> http://www.modest-proposals.com/binary/4thish3.zip
> 
> Rather than have the forth word 'Forth' which holds the link to the latest
> definition, you have 'Context' and 'Current'. 
> 
> 'Context' points to the current named vocabulary which points to the latest
> definition in that vocabulary. 'Find' uses 'Context' to search thru.
> 
> 'Current' points to the current named vocabulary which points to the latest
> definition being compiled to. New definitions are created and linked into
> 'Current'.
> 
> The find vocabulary 'Context' is available to search other vocabularies than
> 'Current'. You can say 'Editor' to invoke search in the Editor vocabulary, but
> still remember the vocabulary you are compiling in.
> 
> Creating a new vocabulary, say 'Editor', creates vocabulary word 'Editor' in
> the parent vocabulary, e.g. 'Forth'. The data field is a zero length name
> and link to the vocabulary 'Forth'. New 'Editor' definitions are linked to
> this data field. When the 'Editor' vocabulary search fails, 'Find' continues
> searching thru the parent vocabulary, 'Forth' in this case.
> 
> This is different from all other forths I have seen which use *hack* hashed
> and or vocabulary stacks. You run out of vocabularies just when you need them
> most or, if hashed, just add needless complications.
> 
> Regards,
> Terry
> 
> >> 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. 
   
> >> Regards
> >> Nick
> >