Digest #10 2016-06-19
It is proposed that Forth 200x compliant implementations would be required to offer a deferred word, wlscope (addr len -- addr' len' wid), whose initial implementation is get-current. All the mechanisms that create new dictionary entries would be required to pass the new name ( addr len ) through wlscope to obtain the destination wordlist ( wid ); the name itself may also be altered, hence ( addr' len' ).
Make it easier to manage inclusion of created words on different wordlists. All large software projects carefully regulate their name spaces. Openfirmware, for example, to separate between the "public" words and the "private" words often groups them as follows:
only forth also hidden also definitions ... also forth definitions ...
With wlscope we would like to take this one step further and allow wordlist switches to be driven by the new name itself, in a way that is completely under the programmer control, through a chain of user defined wlscope functions which analyze and perhaps modify the newly created name and determine to which wordlist it is to be added.
The following shows two wlscope "rules" and how to chain them.
Put helper (factorization) words onto a _local wordlist
\ Wordlist scope that puts words with underscore (_) prefix \ on a _local wordlist. :noname ( addr len -- addr' len' wid ) 2dup 1 > if \ name length check s" _" tuck icompare if \ name prefix check _local exit then else drop then [ ' wlscope defer@ ]l execute ; is wlscope
Grow a special use gui wordlist
vocabulary gui :noname ( addr len -- addr' len' wid ) 2dup 4 > if \ name length check s" gui_" tuck icompare if \ name prefix check swap 4 + swap 4 - \ remove gui_ prefix gui exit then else drop then [ ' wlscope defer@ ]l execute ; is wlscope
: _helper ... ;
would automatically add _helper to the _local wordlist while
: gui_init-gl ... ;
would add init-gl to the gui wordlist.
VM asm code at: core/create/docreate.asm and elsewhere.
amforth and amforth-shadow
Yes, the search order wordset might have been a better place. However, given that TRAVERSE-WORDLIST is in Forth-2012 is in the TOOLS wordset, and there is little point in changing that (given that we don't have wordset queries for Forth-2012, it has no effect on programming). Also, the NAME>... words from the same proposal have nothing to do with the search-order wordset; should we distribute the words from this proposal over several wordsets?
Do we want to limit the Forth implementations to those that are implemented in the way you describe? I don't.
Anyway, don't let my objections stop you. If you think it is worth it, make a proposal.