Attention: The Usenet Article Lookup site has been updated.
The code for this site has been ported from Perl to PHP, so you could say, it is in beta mode. Please contact me if find any problems, or have any suggestions. -- Howard
|Deutsch English Français Italiano|
View for Bookmarking (what is this?)
Look up another Usenet article
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 <firstname.lastname@example.org> Newsgroups: comp.lang.forth Subject: Recognizers terminology (was: Progressing Matthias Trute's recognizer proposal) Date: Tue, 2 Jun 2020 02:44:53 +0300 Organization: A noiseless patient Spider Lines: 100 Message-ID: <email@example.com> References: <firstname.lastname@example.org> <2020May28.email@example.com> <firstname.lastname@example.org> <email@example.com> <2020May28.firstname.lastname@example.org> <email@example.com> <2020May29.firstname.lastname@example.org> <email@example.com> <2020Jun1.firstname.lastname@example.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Mon, 1 Jun 2020 23:44:53 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="dbc8d8512593cf861a2ce1f4fd2c127f"; logging-data="15027"; mail-complaints-to="email@example.com"; posting-account="U2FsdGVkX1/19i5lq2tPtMomLKahUfXY" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 Cancel-Lock: sha1:CSF2/Xh66z8EuktRgi12Y/zB5/0= In-Reply-To: <2020Jun1.firstname.lastname@example.org> Content-Language: en-US Bytes: 5589 On 2020-06-01 19:40, Anton Ertl wrote: > Ruvim <email@example.com> writes: >> On 2020-05-29 19:36, Anton Ertl wrote: >>> Ruvim <firstname.lastname@example.org> writes: > [...] >>> It does not help the discussion if everyone uses his own favourite >>> naming and favourite terminology. In particular, if you want to make >>> point A, and you use your favourite terminology and names (your points >>> B and C), you will fail to get point A across. And of course, you >>> will not make progress on points B and C, because everybody else has >>> their own, different names and terminology, and will ignore this >>> aspect of your posting anyway. >> >> Well, I agree. >> >> So, how can we fix the issues in the terminology? It seems this my question was slightly misunderstood due to my unlucky context. I was thinking about an issue in terminology that I mentioned in response to Alex . See below. . news:email@example.com >> I think they should be fixed even before discussion about mechanisms, >> semantics and names. Perhaps we should start from the scratch, and >> gradually append things from the current proposals step by step. (*) > > I don't think we will get anywhere with this approach: You will make a > proposal with your favourite terminology, which everybody else will > find flawed, so they want to fix the terminology before discussion > about mechanisms, semantics and names; and start from scratch. So the > next one will throw away what you did, just as you want to throw away > what Matthias Trute did, and in the end we will be nowhere. I don't want to throw away what Matthias (or anybody else) did. See above: "should [...] append things from the *current proposals* step by step". > The bottom line is whether you can live with the existing terminology. > I can. And the Forth-200x committee can (I certainly have not heard > complaints about terminology from them). So IMO "fixing" terminology > is at best a waste of time, at worst (and likely) it will result in > never standardizing recognizers. When I talk about *fixing* (i.e., correcting), it is not about favourites, and not about promotion that I did (e.g. by examples that show that the best rectype-null value is 0). It is about that I point to a problem and insist that this problem should be solved. Also, I may suggest some variant of solving, but I don't insist on this variant. I think we should consider all available variants, their pros and cons, and find a consensus. Regarding the terminology. Some problems were already mentioned by Alex, Ulrich, and also me. Just one example of a problem in the terminology. An excerpt from "Recognizer RfD D", XY.3.1 | A data type id is a single cell value that identifies | a certain data type. An excerpt from the Standard | data type: An identifier for the set of values that | a data object may have. So, "data type id" identifies an identifier (i.e. an English title!). Is it an author's intention? Obviously, not. It's just an incompatibility to the language of the Standard. I think, a specification cannot be included into the standard if it conflicts with this standard. The same issue in Ulrich redaction : | Recognizer Information Token: An implementation-dependent | single-cell value that identifies the data type [...] I.e., "Recognizer Information Token" identifies an identifier.  https://forth-standard.org/standard/intro#contribution-131 (*) I suggest to start the next iteration from the terms definitions, i.e., find consensus in the terms definitions at the first, since only such definitions will allow us to use the same clear terminology, and take care from the start that this terminology is compatible to the standard. I have the impression that Recognizer is the most complicated specification among the proposals after 94. One reason is that this specification is really difficult to formally express at the level of the Standard. -- Ruvim