On Wed, 23 Mar 2005, Per Bothner wrote:

> Donovan Kolbly wrote:
> > In general, I don't care as much about the order of arguments, but I do
> > find it's better to ascertain the meaning of an invocation with no more
> > work than counting the number of arguments (i.e., not having to examine
> > the type of the arguments).
>
> I'm used to Java (and C++) overloading so I may have more tolerance for
> selecting depending on argument types.

Ah, sure.  Doesn't Java have a problem with static ambiguity as well?
That is, like C++, it dispatches based on the static type and not the
dynamic type (except for the receiver "this" argument).

Anyway, it seems like overkill for me to define a generic for these, and
usually I want to implement them as syntax (so I can capture compile-time
info like line numbers) which adds another indirection.

Well, it's tractable, just inconvenient.

>
> > In the current spec, test-end is ambiguous:
> >
> >   (test-end [name] [count])
>
> I'm thinking about moving the count to the test-begin.  That might be
> helpful for a test-runner that displays a progress bar, for example:

I like it!

>
> (test-begin name [count])
> (test-end [name])
>
> But in that case should test-group also have a count?
>
> (test-group name [count] form ...)

Probably so, for consistency.  More static ambiguities, though...

>
> > as is test-apply:
> >
> >   (test-apply [runner] specifier ... thunk)
>
> > Furthermore, if test-apply were made to require the runner (the user could
> > supply (test-runner-current) if needed), this would also solve the
> > "implicit runner" problem (*).
>
> No objection to making the runner non-optional - it's not like
> people will be writing lots of test-apply calls.

That was my thinking as well.  So let it be said, so let it be done.

>
> > (*) The "implicit runner" problem:  there are currently two forms which
> > can implicitly create a runner: test-begin and test-apply.  It's obvious
> > how to "finalize" (bring about the invocation of the on-final hook) one
> > created by test-begin, but it's less clear how that should happen for
> > test-apply.  In fact, this is a real problem for my current
> > implementation!
>
> If test-apply creates a new runner, then it should also finalize it.
> Just like test-group/test-begin+test-end do.  Am I missing something?

That would work great.  It just wasn't clear from the spec what was
intended.  Consider my implementation and test suite so adjusted.

>
> It probably is convenient to have a short-hand to run a specific set of
> tests with a default runner being created and finalized.  The use case
> I'm thinking of debugging a test-suite or a specific test.

That makes sense.  So far, I've only been running complete suites, even
while debugging specific tests, but you would definitely want that.

--
-- Donovan Kolbly                    (  xxxxxx@rscheme.org
				     (  http://www.rscheme.org/~donovan/