Path: ...!news.mixmin.net!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Ruvim Newsgroups: comp.lang.forth Subject: Re: Problem of FIND, rethinking Date: Wed, 19 May 2021 01:43:03 +0300 Organization: A noiseless patient Spider Lines: 102 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Tue, 18 May 2021 22:43:05 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="fc35f5c99508cc31eec9b0ff5d4b700c"; logging-data="16848"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+28nEZ8A+LuHekp2ODkWBc" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 Cancel-Lock: sha1:UFCpNeix1kk6J3sBtqXzKbMz1Qw= In-Reply-To: Content-Language: en-US X-Mozilla-News-Host: news://nntp.aioe.org Bytes: 5278 On 2021-05-10 04:15, Ruvim wrote: > > The Forth text interpreter has to perform the semantics for a name (for > a lexeme in the general case) according to STATE. In interpretation > state it has to perform IS for the name, in compilation semantics it has > to perform CS for the name. > > (For shortness I use the following acronyms: IS - interpretation > semantics, CS - compilation semantics, ES - execution semantics) > > > Performing semantics for a name is usually broken up into two steps: >   1) name resolution (to find semantics for a name) >   2) applying the result of resolution (to perform semantics). > > And there are two opposite options in these steps concerning STATE: >   A) name resolution doesn't depend on STATE, but applying depends. >   B) name resolution depends on STATE, but applying doesn't depend. > > According to these options, two type (two implementation approaches) of > Forth systems existed: single-xt and dual-nt systems. > > "single-xt system" means a system with the single header per word > (single-nt), one xt in this header (single-xt), and the immediacy flag. > > "dual-nt system" means a system with two headers per word (dual-nt), and > one xt in each header, so two xts per word (dual-xt). > > > The single-xt systems stick to the option A. > > The dual-nt systems stick to the option B. > Actually this classification implies solely the user's (program's) point of view. Having a full-fledged "FIND", a standard Forth-94 program can detect whether a system uses the single-xt approach, or the dual-xt approach. But it cannot detect whether a system uses the dual-nt approach. Perhaps a Forth-2012 program can detect whether a system uses the dual-nt approach in some rare cases. So we can introduce the following formal definitions (alpha version). Definition: an ordinary word is a word that has default interpretation semantics and default compilation semantics (namely, it's a word for which the interpretation semantics are to perform its execution semantics in interpretation state, and for which the compilation semantics are to append its execution semantics to the current definition). Definition: a dual-semantics word is a word that is not ordinary, and for which the interpretation semantics are not equivalent to the compilation semantics (at least for some arguments). Definition: a single-xt system is a Forth system in which "FIND" for neither word returns the different results among interpretation state and compilation state, and for neither word Tick "'" or "SEARCH-WORDLIST" returns the xt that is different from the xt that "FIND" returns for this word. Definition: a dual-xt system is a Forth system that is not a single-xt system. Definition: a strict dual-xt system is a Forth system that provides dual-semantics words, and among the definitions that "FIND" returns to perform compilation semantics, neither one depends on whether it's performed in compilation state or in interpretation state. A rationale concerning the strict dual-xt systems: - we distinct the strict dual-xt systems since a dual-xt system can be a hybrid system where both steps (name resolution, and applying the result of the resolution) depend on STATE (at least for some words); - two different xt-s can identify the same execution semantics, hence if "FIND" depends on STATE it still doesn't mean that it returns the different semantics, but it can be a trivial case of the different xt with the same semantics; to exclude the systems that are limited by only trivial cases, the definition requires a system to provide dual-semantics words. [...] > Thus, one problem of FIND is that it should satisfy two implementation > approaches, that are opposite each other in some sense. > > > That's why FIND is allowed to return the different results depending on > STATE. And that's why compilation semantics are allowed to be performed > only in compilation state (ditto for IS). > > > > The story will be continued. > -- Ruvim