Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Flunking tests and failing code

0 views
Skip to first unread message

Gaal Yahas

unread,
Dec 5, 2005, 1:37:49 AM12/5/05
to perl6-l...@perl.org
There's a bikeshedding question of some visibility: now that we have a
C<fail> builtin, what do we do with C<Test::fail>?

There's plenty of code out there that uses fail as an exported function
from pugs' Test.pm or Perl 5 testing modules. We want to keep Test
primitives exported and fun to use, to encourage people to use them a
lot; so requiring a fully qualified call would go against the grain.
But the builtin has even more of that concern: it should become the more
common, too. If one is to be renamed, it looks like is the Test one,
despite existing legacy code.

Discussion on #perl6 brought up &flunk as a candidate name. Its merits,
including its, uh, dropout cuteness, are many; it rings well against
fail, alludes to tests, can probably be backported to the Perl 5 test
modules, etc.

What say?

[++] <dduncan autrijus>

--
Gaal Yahas <ga...@forum2.org>
http://gaal.livejournal.com/

Luke Palmer

unread,
Dec 5, 2005, 2:54:25 AM12/5/05
to Gaal Yahas, perl6-l...@perl.org
On 12/5/05, Gaal Yahas <ga...@forum2.org> wrote:
> There's a bikeshedding question of some visibility: now that we have a
> C<fail> builtin, what do we do with C<Test::fail>?

Is it possible to do nothing with it? That is, can we coerce the Test
module to understand when the main program "fail"s? This may be
problematic, as it is occasionally desirable to call "fail" from
within a function while you are testing.

There's another problem that I've been thinking about with regard to
Test. We have the prefix:<is> builtin, used like so:

class Foo {
is Bar;
}

Which can be interpreted as a regular compile-time function (I guess
we call those macros) that acts on some topic container (think io[1]).
So we seem to have stolen that from Test, too.

I wonder if there is a macroey thing that we can do here. That is,
could we make:

ok(1);
is(1, 1);
like("foo", /foo/);

Into:

ok(1);
ok(1 == 1);
ok("foo" ~~ /foo/);

And lexically analyze the argument to ok() to find out how to report
the error? Something in the style of Smart::Comments which looks at
subexpressions and tells you about them automatically.

The only downside is that you can't refer to &ok as a coderef. I
think that is a small price to pay for such a wonderful DWIMmity.

Luke

[1] http://www.iolanguage.com

Brent 'Dax' Royal-Gordon

unread,
Dec 5, 2005, 3:17:19 AM12/5/05
to Luke Palmer, Gaal Yahas, perl6-l...@perl.org
Luke Palmer <lrpa...@gmail.com> wrote:
> I wonder if there is a macroey thing that we can do here. That is,
> could we make:
>
> ok(1);
> is(1, 1);
> like("foo", /foo/);
>
> Into:
>
> ok(1);
> ok(1 == 1);
> ok("foo" ~~ /foo/);
>
> And lexically analyze the argument to ok() to find out how to report
> the error? Something in the style of Smart::Comments which looks at
> subexpressions and tells you about them automatically.

It strikes me that the test framework is probably the one part of the
libraries where simplicity is more important than DWIMmery, lest a
Perl bug manifest itself somewhere deep in the bowels of the test
framework itself.

--
Brent 'Dax' Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker

Nathan Gray

unread,
Dec 5, 2005, 8:28:34 PM12/5/05
to Luke Palmer, Gaal Yahas, perl6-l...@perl.org
On Mon, Dec 05, 2005 at 07:54:25AM +0000, Luke Palmer wrote:
> I wonder if there is a macroey thing that we can do here. That is,
> could we make:
>
> ok(1);
> is(1, 1);
> like("foo", /foo/);
>
> Into:
>
> ok(1);
> ok(1 == 1);
> ok("foo" ~~ /foo/);
>
> And lexically analyze the argument to ok() to find out how to report
> the error? Something in the style of Smart::Comments which looks at
> subexpressions and tells you about them automatically.

I like that a lot.

-kolibrie

Ruud H.G. van Tol

unread,
Dec 5, 2005, 9:13:37 PM12/5/05
to perl6-l...@perl.org
Nathan Gray:
> Luke Palmer:

>> I wonder if there is a macroey thing that we can do here. That is,
>> could we make:
>>
>> ok(1);
>> is(1, 1);
>> like("foo", /foo/);
>>
>> Into:
>>
>> ok(1);
>> ok(1 == 1);
>> ok("foo" ~~ /foo/);
>>
>> And lexically analyze the argument to ok() to find out how to report
>> the error? Something in the style of Smart::Comments which looks at
>> subexpressions and tells you about them automatically.
>
> I like that a lot.

ok("that" ~~~~~~~~~ /I/)

--
Grtz, Ruud

Chromatic

unread,
Dec 5, 2005, 10:04:06 PM12/5/05
to Luke Palmer, perl6-l...@perl.org
On Mon, 2005-12-05 at 07:54 +0000, Luke Palmer wrote:

> I wonder if there is a macroey thing that we can do here. That is,
> could we make:
>
> ok(1);
> is(1, 1);
> like("foo", /foo/);
>
> Into:
>
> ok(1);
> ok(1 == 1);
> ok("foo" ~~ /foo/);

Can you do it without giving up the nice diagnostics that
Test::More::is() provides?

Note that Test.pm in Perl 5 uses ok() for everything and that DWIMmery
too often doesn't.

-- c

Luke Palmer

unread,
Dec 6, 2005, 9:02:16 AM12/6/05
to chromatic, perl6-l...@perl.org
On 12/6/05, chromatic <chro...@wgz.org> wrote:
> On Mon, 2005-12-05 at 07:54 +0000, Luke Palmer wrote:
>
> > I wonder if there is a macroey thing that we can do here. That is,
> > could we make:
> >
> > ok(1);
> > is(1, 1);
> > like("foo", /foo/);
> >
> > Into:
> >
> > ok(1);
> > ok(1 == 1);
> > ok("foo" ~~ /foo/);
>
> Can you do it without giving up the nice diagnostics that
> Test::More::is() provides?

The answer to your question was in the next sentence:

> > And lexically analyze the argument to ok() to find
> > out how to report the error?

I guess that wasn't much of an answer, but more of a question.
Anyway, yes, that is what I was hoping. However, I agree with Brent
Dax about keeping the test module simple--at least for the compiler
test suite. However, I think this DWIMmery might work well in module
test suites.

That still leaves the problem of what to do with fail() and is() in
the compiler suite.

Here's a handwavey crack at what I was talking about:

my $comparators = set <== ~~ eq
macro is($arg, ?$reason_tree) {
my $reason = $reason_tree.run;

Luke Palmer

unread,
Dec 6, 2005, 9:09:28 AM12/6/05
to chromatic, perl6-l...@perl.org
On 12/6/05, Luke Palmer <lrpa...@gmail.com> wrote:
> That still leaves the problem of what to do with fail() and is() in
> the compiler suite.
>
> Here's a handwavey crack at what I was talking about:

Ack. Accidentally sent the half written message. Let's try again:

my $comparators = set < == eq === ~~ < lt ... >
macro is($arg, ?$reason_tree) {
if $arg ~~ :(App (func => my $f, args => my @args))
&& $f (in) $comparators {
"internal_ok($arg, '@args[0] $f @args[1] failed: ' ~ $reason_tree)"
}
else {
"internal_ok($arg, $reason_tree)"
}
}

Except hopefully with quasiquoting instead of simple interpolation.

Luke

0 new messages