new implementation Arthur A. Gleckler (21 Feb 2020 21:37 UTC)
Re: new implementation Lassi Kortela (21 Feb 2020 23:25 UTC)
Re: new implementation Per Bothner (22 Feb 2020 00:17 UTC)
Re: new implementation Arthur A. Gleckler (22 Feb 2020 00:33 UTC)
(missing)
Re: new implementation Arthur A. Gleckler (23 Feb 2020 18:58 UTC)
Re: new implementation Arthur A. Gleckler (23 Feb 2020 20:09 UTC)
Re: new implementation Taylan Kammer (23 Feb 2020 22:25 UTC)
Re: new implementation Per Bothner (23 Feb 2020 22:55 UTC)

Re: new implementation Taylan Kammer 23 Feb 2020 22:25 UTC

On 22.02.2020 01:17, Per Bothner wrote:
> On 2/21/20 1:37 PM, Arthur A. Gleckler wrote:
>> Taylan Kammer has provided an alternative implementation of the widely
>> used SRFI 64: A Scheme API for test suites.  I've added it to the Git
>> repo under contrib/
>> <https://github.com/scheme-requests-for-implementation/srfi-64/tree/master/contrib/taylan.kammer>.
>>
>
> Great.  However, it would be nice if the README were fleshed out comparing
> the functionality/portability and other differences between the implementations.
>
> For example, one advantage of the reference implementation is that it has
> hooks for reporting line numbers for failing tests. That seems impossibly to
> do portably, and difficult to do without some kind of macro hooks.

My implementation also reports line numbers.  I'm not sure if there's a
difference there.

As advantages for my implementation, I'd list:

- Based on R7RS: dropping support for non-R7RS environments simplifies
the code, since workarounds like using a vector for a mock record type,
or using cond-expand to support implementation-specific exception
handling mechanisms, can be removed.

- Modular design: the source is split into four components: Execution
(forms to actually execute tests), test-runner (the data type),
test-runner-simple (the "simple" test runner defined by the standard),
and source-info (shims to support source info gathering).  Note that
these aren't actually exposed as sub-libraries, since that might
encourage writing code that only works with this implementation; the
separation is only for ease of understanding and navigation of the code.

- Improved code clarity: using shims to hide implementation-specific
code for source info gathering further eliminates the use of cond-expand
in the main body of the code, improving readability.

All in all, my implementation basically came into existence as a
refactoring (maybe since rewrite) of the reference implementation, as
I'm a code clarity pedant and had difficulties grokking the reference
implementation.

Taylan

(P.S. I'm re-sending this email to the mailing list since it didn't get
through the last time.)