[imp-hackers] Another topic: ANSI standard test suite

Sam Steingold sds at gnu.org
Fri Jun 26 15:31:50 UTC 2009


On Fri, Jun 26, 2009 at 11:18 AM, Juan Jose
Garcia-Ripoll<juanjose.garciaripoll at googlemail.com> wrote:
> On Fri, Jun 26, 2009 at 5:08 PM, Sam Steingold<sds at gnu.org> wrote:
>
>> Moreover, since this is an ANSI test suite, no #+clisp/#+gcl/#+abcl
>> should ever be present there.
>> if several results are permitted by the standard, each should be
>> accepted from any implementation.
>
> ... I strongly disagree on this.
>
> The ANSI test suite has _always_ contained conditionalizations and it
> will most likely contain more if we extend it reasonably. How would
> you test for instance external formats when the names of these formats
> are not even standard, but rather implementation dependent. Not all
> tests will make sense on all implementations.

the common test suite is no substitute for implementation-specific suites.
implementation-specific features are best kept there.

> Furthermore, I also advocate testing non-standard extensions and
> things that are de-facto standards, such as CLRFI-like additions or
> things that several implementations may agree to support. In other
> words, it can be more than just a plain ANSI test suite, clearly
> marking which tests results belong to ANSI and which do not.

the common test suite should test for common features, i.e., those
features which are either ansi standard or a result of a wide
consensus.
if there is a consensus, conditions are not necessary.
if there is no consensus, the test does not belong to the common test suite.

however, this, IMO, is secondary to the main notion that we need the
common ansi test suite in an implementation-independent repository.

if we all agree on the latter, we can discuss which service to use
(savannah, sourceforge &c) and the VC system (hg, svn &c).

-- 
Sam Steingold <http://sds.podval.org>




More information about the implementation-hackers mailing list