bug#74385: [PATCH 3/4] srfi-64: Export define-equality-test.
Ludovic Courtès writes:
> Hi Tomas,
>
> Tomas Volf <~@wolfsden.cz> skribis:
>
>> +(define-syntax define-equality-test
>>(syntax-rules ()
>> ((_ name test-proc)
>> (define-syntax name
>> (λ (x)
>> (syntax-case x ()
>> ((_ test-name expected test-expr)
>> -#`(%%test-2 #,x test-proc test-name expected test-expr))
>> +#`(%test-2 #,x test-proc test-name expected test-expr))
>> ((_ expected test-expr)
>> -#`(%%test-2 #,x test-proc #fexpected test-expr
>> +#`(%test-2 #,x test-proc #fexpected test-expr
>> +(set-documentation! 'define-equality-test
>> + "@defspec define-equality-test identifier proc
>> +Define a new test form named @var{identifier} with same signature and usage
>> as
>> +@code{test-eq} but using @var{proc} instead of @code{eq?}.
>
> I didn’t notice earlier, but you can add docstrings like this:
>
> (define-syntax define-equality-test
> (syntax-rules ()
> "This is the docstring."
> …))
Ah, good catch. Since that works just for syntax-rules and not
syntax-case, I probably did not moved the documentation string around
when switching between them. Will update.
>
> As for exporting ‘define-equality-test’, I would clearly mark it as a
> “GNU extension”.
>
> The way this was done before is by having more exports in a separate
> module, like (srfi srfi-9 gnu).
>
> Whether or not you pick this approach, please make sure to document it
> in the manual and to prominently mark it as a GNU extension.
I personally think that leaving it in one module is fine, and I agree it
should be documented. There are other GNU extensions already in the new
SRFI-64, and I plan to document all once #71300 is merged. I will wait
for v2 until that happens and will include the documentation changes
required.
Have a nice day,
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
signature.asc
Description: PGP signature
bug#74385: [PATCH 4/4] srfi-64: Report failed tests in (standards)Errors format.
Ludovic Courtès writes: > Tomas Volf <~@wolfsden.cz> skribis: > >> There is a page in the GNU Standards document regarding the format of error >> messages. Both GNU Emacs and Vim are able to parse it and support jumping to >> next/previous error. My version did not produce a line in this format for >> failed tests and this commit rectifies that. >> >> * module/srfi/srfi-64.scm (test-on-test-end-simple)[non-passed]: Write >> out (standards)Errors compatible line. >> >> Reported-by: Janneke Nieuwenhuizen > > I personally like this but my gut feeling is that we may want to stick > to whatever the previous SRFI-64 implementation was doing, to avoid > disruption or breakage for users (remember we’re applying this to a > stable series). I agree that the output of the simple test runner of the current and the reference versions do differ, by necessity. I tested the change in Emacs and it seems to work out of the box, the compilation buffer correctly navigates to the locations. However I understand your worries regarding the stable series. What I would suggest is that I can extract the test runner from the reference implementation, and package it as reference/test-runner-simple. User then could, with a simple code change, use it instead of the new compliant runner. I would even go as far as to provide a mechanism to select the runner by environment, so GUILE_SRFI64_DEFAULT_TEST_RUNNER=reference would cause test-runner-factory to return reference/test-runner-simple. If unset or empty value, it would use the new runner as it does now. This will allow restoring the previous output format even with no code changes. Combined with NEWS entry, that could be sufficient? What do you think? Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
