16.6.1.1550 FIND SEARCH
Find the definition named in the counted string at c-addr. If the definition is not found after searching all the word lists in the search order, return c-addr and zero. If the definition is found, return xt. If the definition is immediate, also return one (1); otherwise also return minus-one (-1). For a given string, the values returned by FIND while compiling may differ from those returned while not compiling.
See:
Implementation:
#order and context are defined as per E.16.6.1.1647 GET-ORDER.
0 ( c-addr 0 )
#order @ 0 ?DO
OVER COUNT ( c-addr 0 c-addr' u )
I CELLS context + @ ( c-addr 0 c-addr' u wid )
SEARCH-WORDLIST ( c-addr 0; 0 | w 1 | q -1 )
?DUP IF ( c-addr 0; w 1 | w -1 )
2SWAP 2DROP LEAVE ( w 1 | w -1 )
THEN ( c-addr 0 )
LOOP ( c-addr 0 | w 1 | w -1 )
;
Testing:
ContributeContributions
lmr
[327] diff from CORE FIND?Request for clarification2023-12-31 13:04:17
Maybe I'm missing something obvious, but how is this an extension of CORE FIND? It seems like exactly the same wording.
AntonErtl
The difference is that the search order version contains the following words, but the core version does not:
after searching all the word lists in the search order
AntonErtl
In the latest draft, there is really no difference between core FIND and search-order FIND, because the difference has been factored out into Sections 3.4.2 and 16.3.3, as well as into 2.1 and 16.2.
Therefore I propose to delete 16.6.1.1550 FIND, and instead add a link to 16.3.3 to 6.1.1550 FIND. Given that we already have this contribution, I just reopen it instead of creating a new proposal.