Path: ...!weretis.net!feeder6.news.weretis.net!feeder7.news.weretis.net!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Ruvim <ruvim.pinka@gmail.com> Newsgroups: comp.lang.forth Subject: Re: FIND-based text interpreter Date: Wed, 9 Oct 2019 16:40:35 +0300 Organization: A noiseless patient Spider Lines: 150 Message-ID: <qnko0l$jk2$1@dont-email.me> References: <qlqjtl$1vv$1@dont-email.me> <qlue2o$aae$1@dont-email.me> <2019Sep19.185546@mips.complang.tuwien.ac.at> <qm5aec$fll$1@dont-email.me> <2019Sep21.164152@mips.complang.tuwien.ac.at> <qnfmj1$qpv$1@dont-email.me> <2019Oct8.183509@mips.complang.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Wed, 9 Oct 2019 13:40:37 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="d50a43f2fd9e2e7a6c6d6f6d32613491"; logging-data="20098"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18r2AzzanPR0E6ohcB28aYc" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cancel-Lock: sha1:aYQfTFl+4taiH73Kw22+NmV/4/Q= In-Reply-To: <2019Oct8.183509@mips.complang.tuwien.ac.at> Content-Language: en-US X-Mozilla-News-Host: news://nntp.aioe.org Bytes: 6624 On 2019-10-08 19:35, Anton Ertl wrote: > Ruvim <ruvim.pinka@gmail.com> writes: >> On 2019-09-21 17:41, Anton Ertl wrote: [...] >>> The "Clarify FIND" proposal >>> <http://forth-standard.org/standard/core/FIND#reply-165> is intended >>> to resolve this.[1] > .... >>> FIND does not know whether it is used in a text interpreter or for >>> something else. If you return c-addr 0, a text interpreter will not >>> be able to text-interpret TO and IF. >> >> I'm now inclined to think that FIND was *intended* to be used in the >> Forth text interpreter *only*. > > I don't think that the Forth-94 committee had that intention. Perhaps I have expressed my thought wrongly. I wanted to say that FIND, at the first, should respond to the requirements of the text interpreter. And other possible use cases have far less weight. > I think > the intention was to expose a classically available word that is used > in the text interpreter, in ' and POSTPONE to the user, in particular > for user-defined text interpreters. And I think that you can, e.g., > implement POSTPONE and ' based on FIND once FIND is sufficiently > defined (as in my proposal). Yes, Tick and POSTPONE should be implementable over FIND. >>>> In any case, there is no standard way to implement a full-fledged >>>> user-defined text interpreter in Forth-2012. >>> >>> Yes, FIND is defined too loosely for that. >> >> Not only that. >> >> Another important thing is that there is no way to restore (or reset) >> the interpreter state after an error. For example, locals for an >> unfinished colon definition could be left in the scope. > > POSTPONE ; > > might do the trick. And if that produces an error, you have to think > about how to stay within the user-defined text interpreter. It can produce an error due to control structure mismatch. Therefore, I even didn't try, and was forced to restart my "quit" again after any error. >> A system's text interpreter is provided as QUIT word. But a user can't >> implement an alternative functionality without re-implementing a much >> part of the Forth system. > > True. The recognizer proposal proposes to replace the core of the > text interpreter with one that works through the user-reconfigurable > recognizer queue/stack, allowing to reuse the rest of the text > interpreter infrastructure (error catching, INCLUDE, EVALUATE, LOAD, > etc.). Yes, recognizers help. But they cannot help to implement QUIT alternative in regards to reset the states after an error. There need another API. >>> : find ( c-addr -- xt n | c-addr 0 ) >>> dup count find-name ?dup if >> Don't you need 'dup' instead of '?dup' here? > > Yes. > >>> nip dup name>interpret swap name>compile >r ( xti xt1 R: xt2 ) >>> state @ if swap then drop ( xt R: xt2 ) >>> r> ['] execute = ( xt 0|-1 ) -2 * 1- ( xt -1|1 ) >>> then ; >> >> It seems the variant when n=1 in interpretation state doesn't have much >> sense in your proposal [1]. > > Yes, it makes no difference for a typical user-defined text > interpreter. However, if you have a classic > single-xt-plus-immediate-flag system, FIND returns the same values in > either STATE, and the FIND implementation above will behave the same > way. So if you have a usage of FIND that relies on this property, the > FIND above will work. It seems for me that your proposal is not fine enough for single-xt-plus-immediate-flag systems, see bellow. >> Why not the following? >> >> : find ( c-addr -- xt n | c-addr 0 ) >> dup count find-name dup 0= if exit then ( c-addr nt ) >> state @ if nip name>compile ['] execute = -2 * 1- exit then >> name>interpret ( c-addr xt|0 ) dup if nip -1 exit then >> ; > > This version would always return "xt -1" in interpret state, and some > (system-specific) users of FIND might prefer my FIND implementation > (after bug-fixing). It is reasonable, but I think a system-specific using of FIND already doesn't matter, since FIND is provided for compatibility only (i.e. for programs). So, the question is — what about programs? : foo ; immediate : bar c" foo" find nip 1 = ; bar . A standard program may assume that bar returns -1. But according to your proposal, bar *may* return 0 in this case. Since your specification for FIND does not dictate what to return in interpretation state (1 or -1) and in what case. And what it means. I think it is a problem. Another problem is that your proposal doesn't allow to implement the words with undefined execution semantics as STATE-dependent immediate words. But the original specification allows that. >> Also, in the general case, when 'name>compile' can return xt2 other than >> 'compile,' and 'execute', the code becomes slightly more complex: it >> should return (c-addr 0) if xt2 is neither of them. > > In this case FIND should return something equivalent to: > > :noname xt1 xt2 execute ; > > as xt and 1 as n. Yes, it is technically possible, but perhaps it isn't worth effort in all the cases. -- Ruvim