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: 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: <rb43tl$elj$1@dont-email.me>
References: <ramao9$3og$1@dont-email.me>
 <2020May28.092537@mips.complang.tuwien.ac.at> <raobl0$5r3$1@dont-email.me>
 <raojpu$s27$1@dont-email.me> <2020May28.191153@mips.complang.tuwien.ac.at>
 <rar8gg$r1p$1@dont-email.me> <2020May29.183609@mips.complang.tuwien.ac.at>
 <rarmuk$40d$1@dont-email.me> <2020Jun1.184023@mips.complang.tuwien.ac.at>
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="abuse@eternal-september.org";	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.184023@mips.complang.tuwien.ac.at>
Content-Language: en-US
Bytes: 5589

On 2020-06-01 19:40, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2020-05-29 19:36, Anton Ertl wrote:
>>> Ruvim <ruvim.pinka@gmail.com> 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 [1]. See below.

[1]. news:rarbcg$fsl$1@dont-email.me


>> 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 [2]:
| Recognizer Information Token: An implementation-dependent
| single-cell value that identifies the data type [...]

I.e., "Recognizer Information Token" identifies an identifier.

[2] 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