Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Gerry Jackson <do-not-use@swldwa.uk>
Newsgroups: comp.lang.forth
Subject: Re: single-xt approach in the standard
Date: Wed, 18 Sep 2024 21:59:36 +0100
Organization: A noiseless patient Spider
Lines: 76
Message-ID: <vcfevo$6m9q$1@dont-email.me>
References: <vcbn5e$3etuk$1@dont-email.me>
 <d85ac3d9a2e6f7af161993b33b10c890@www.novabbs.com>
 <vcbqvk$3etuk$2@dont-email.me> <vccjfv$3l9rv$1@dont-email.me>
 <vce3sj$3unj9$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 18 Sep 2024 22:59:36 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="774eabdf09d9b06923882939691ac05a";
	logging-data="219450"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ifYmW5elDjwfMPlpXQtQinDiVxwk4Le4="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:0YR+SMTe9B7NnDOlb3CZK13WPyE=
Content-Language: en-GB
In-Reply-To: <vce3sj$3unj9$4@dont-email.me>
Bytes: 4703

On 18/09/2024 09:44, Ruvim wrote:
> On 2024-09-17 22:58, Anthony Howe wrote:
>> On 2024-09-17 07:59, Ruvim wrote:
>>> On 2024-09-17 15:20, minforth wrote:
>>>> I would like to see an "officially recognized" standard reference
>>>> system, speed and number of xt's per word are of no importance.
>>>>
>>>> Are you planning to make one?
>>>
>>> I think, having the single standard reference implementation is a big 
>>> step back in Forth standardization process. Because implementation 
>>> details of the particular implementation will be used as requirements.
>>
>> I think it should be recognised in some capacity, given Forth's 
>> origins, but whether there should be a reference implementation 
>> probably not.
>>
>>
>>> I think, the standard conformance test suite is enough.
>>
>> One would think so, but the test suite is:
>>
>> * incomplete
>> * as published in draft 19-1 has typos and possible errors
>> * test cases often test multiple words at once that have not be tested 
>> separately
>> * assumes the entire draft with all the optional sets are present, 
>> rather than separate the word sets into separate unit tests
> 
> There is another testsuite:
> https://github.com/gerryjackson/forth2012-test-suite

Just to put the record straight, The Forth Test suite in the Forth 200X 
standard draft 19.1 incorporates most of my test suite with the addition 
of, for example, tests for new words such as FIND-NAME and FIND-NAME-IN.

> 
> 
> I have an idea for a testsuite that:
>    — is a ready-to-use program;
>    — does not use words from optional word sets (for that, all the 
> source files are transpiled into a single file that can be passed to 
> stdin);
>    — does not change the host Forth system (for example, does not add 
> the missed standard words);
>    — has an external program that parses output of the testsuite from 
> the host's Forth system stdout and generates a report in text/xml/xhtml 
> form;
>    — includes into the report general information such as implemented 
> words and word sets, implementation options (that can be inferred by a 
> standard program), the behavior of some words in edge cases, etc., along 
> with the lists of passed and failed tests;
>    — has a configuration for a number of known systems (that is extended 
> by the community);
> 
Some of these, particularly the reporting has been suggested before but, 
as you pointed out elsewhere everybody is an unpaid volunteer and nobody 
has found the time or motivation to undertake such extensions. Are you 
volunteering? I've just requested that the Forth 200X committee find 
someone else to take over my test suite - so feel free to volunteer.

One thing not included in the Test Suite in the standard, as far as I 
can see,  and not mentioned in your wish list is that the Hayes tester 
assumes so much of the system is working before the tests actually start 
- how do you test the tester? I thought about this and developed a 
preliminary test based on the assumption that for automated testing at 
least the interpreter must work. So it starts by using SOURCE TYPE ( 
comments ) and CR to output messages and include a commentary of how the 
tests progress. If the displays are correct it tests >IN manipulation 
and uses it as an interpretive IF to actually detect errors. Then it 
goes on to do a basic test of the words used in the Hayes tester and so 
on. This is included in the link above.

-- 
Gerry