Per Bothner <xxxxxx@bothner.com> writes:

> I tried running your version of the test.  It turns out it is
> not "pure R7RS", at least not by itself, as it depends on functions
> from srfi-1, srfi-13, and srfi-28 (format), a least.

Well, those can (and are) in turn implemented in pure R7RS, in the same
repository.  (Only 'string-titlecase' of SRFI-13 is problematic, but
that's not used here.)

It seems I forgot to add the import for SRFI-13 in my commit from
yesterday though (I implemented the whole-path printing for tests, hence
string-join).  Fixed.

(BTW instead of SRFI-28, SRFI-48 is imported.  Not sure if any of its
features are used but it's also written in R7RS in the same repo.)

> Your runner doesn't print anything until the very end.  I think
> it is better to print out the results as you go, in case of some
> uncaught error crashing the test.

Hmm, for me it prints [PASS], [FAIL], etc. as I go.  Not sure what
happened there.  Could it be some buffering on your side?

E.g. I'm working on a test suite in the REPL right now:

xxxxxx@(guile-user)>  [... snipped out ...]
Group begin: struct
[PASS] bytestructures/struct/create
Group begin: procedural
[PASS] bytestructures/struct/procedural/ref
ERROR: In procedure scm-error:
ERROR: No such struct field. 1
Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
xxxxxx@(guile-user) [1]> ,quit
Group end: procedural
Group end: struct
xxxxxx@(guile-user)>

(Guile doesn't have full R7RS support yet so I'm using it with 'guard'
from (rnrs exceptions (6)), which apparently only catches R6RS
conditions, so we see no [FAIL] after the exception, but we see the
group endings because they use unwind-protect.)

> Having the default runner print out a PASS line for every passing
> test is needlessly verbose.  That is why my runner only prints out
> unexpected results plus a summary; the details, including passing
> tests, are in the log file.

It's the behavior I'm used to from most programs' "make check".  Since
the number of failures is printed at the end, the user can just search
upwards for "FAIL" when it's non-zero.  This is a fairly unimportant
difference IMO.

>> I agree [line numbers are] quite convenient ...., but I found the
>> trade-off between the offered convenience and the complexity added to
>> the code to be in favor of removing the feature.
>
> I disagree with this trade-off.  Line-number reporting isn't quite
> essential, but it makes using the framework much more friendly.
> And if the feature is already implemented and works (at least on
> Kawa, Guile-2, and [some old version of] mzscheme) it would be
> a shame to remove a working useful feature.

Actually, I might add it (back) in a modularized form.  Indeed the whole
thing might benefit from more modularity, like splitting the "simple
test runner" code into a different file as well.  Then some of my
complaints about over-complicatedness wouldn't apply anymore.  I don't
know why I didn't think of this before, since we can use both 'include'
and sub-libraries in R7RS.  I guess I'll work on it soon.

Thanks for the input!

Taylan