Re: RFD: Built-in testing
Hi
I assume that BDD(Behavior Driven Development) and the vocabulary that
it implies is not a good choice
at this stage ?
:describe("");
$x.should be(1e5) :it("");
and that a module based on the core testing facilities can be built if
someone feels like to.
Well, the vocabulary that it implies is really nice anyway if it can be
of any inspiration^^
http://www.oreillynet.com/pub/a/ruby/2007/08/09/behavior-driven-development-using-ruby-part-1.html
Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)
Dave Whipp wrote:
I do agree that a prelude.pm should be written atas higher level as
possible, but I would not that Perl6 is not a "declarative" language.
Using the most powerful operators available (I'd like to see more of
them) is about the best you can do: as soon at you start using
codeblocks to define things, you get beyond the realm where compile-time
analysis is possible in a dynamic language.
Lets imagine I want to define a "sqrt($x)" function in a declarative
style in perl6 (and lets image we've defined a Real type with
Real::Epsilon being the precision of the representation). The
declarative version of sqrt must say to find a value within the set of
Real numbers that, when squared, is closest to $x:
sub sqrt(Num where { 0 <= $_ <= Real::Max } $x) {
(0..$x/2 :by(Real::Epsilon)).min: { abs $x - $^candidate ** 2 }
}
So do you really mean "as declarative a manner as possible"? Or would
you consider this example to go beyond "possible"?
I would declare sqrt this way instead (the body is the important change):
sub sqrt(Num where { 0 <= $_ <= Real::Max } $x) {
$x ** (1/2)
}
My point with this example is that any time there exists 2 operators for which
one is a more specialized case of the other, or the other is a more generalized
case of the first, then the specialized one is defined in terms of the
generalized one.
So defining sqrt as just a special case of exponentiation makes for a simple
declarative solution.
I think when I said "define in terms of higher level", I also meant to say
"define in terms of the most generalized operators applicable".
Note also that, as I've defined it, sqrt is still defined in exact terms rather
than approximate / precision-varying terms, and so each underlying
implementation can easily interpret this as an exact math operation if it is
itself capable of exact math, and otherwise it still has enough information to
know how to do it in approximate math.
-- Darren Duncan
Re: RFD: Built-in testing
Larry observed:
> My feeling on this is that the compiler should simply hardwire this
> particular adverb so that all the tests can be autogenerated, and the
> multi system never needs to see those versions.
I strongly agree.
> We are merely hijacking the adverb syntax so that is clear which
> operator is being modified. There is no need for the late binding of
> multi. It's just a "reserved adverb" if you will. Which probably means
> it should be something unlikely to collide with user-defined adverbs.
> Maybe something in all caps. For what it's worth, :OK<> can be typed
> with one hand while the other holds down the shift key. :)
Typical right-hander fascism!
We do indeed want to encourage testing by making it easy to write tests,
but naming it :TEST<> makes it far easier to *read* tests, which seems
to me a better long-term optimization.
We would probably also want a mechanism for switching tests on or off in
a given compilation unit, or globally, so they can be placed in (and left in!)
production code. Perhaps we could use the same mechanism for PRE{...}
and POST{...} blocks as well? Which also suggests that a general TEST
{...} block (which only runs if testing is enabled) might be valuable?
Damian
Re: RFD: Built-in testing
Hi, I pretty much like this idea. Very perl6ish :) - I don't think it's important whether it is called :ok, :OK or :test or :wellhowdidthatworkout. I assume people who will be testing their modules/code/etc. will be using more advanced modules for testing anyway. This is for testing the implementation against the specs, and they *will* know how it works :) - I don't think we should be concerned whether to implement :ok is difficult. Implementations in early stage are totally broken anyway :), they won't even *parse* the tests well - they will have have their own, limited tests. Later they can chose to do some magic to make :ok work... and finally implement it. - I like "ok" better than "test", as the former kind of implies a boolean "was that true?" to me. YMMV, though. - Fagzal
Re: RFD: Built-in testing
On Tue, Jan 20, 2009 at 1:08 PM, Moritz Lenz wrote:
> So Larry and Patrick developed the idea of creating an
> adverb on the test operator instead:
>
>$x == 1e5 :ok('the :ok makes this is a test');
>
> This is an adverb on the infix:<==> operator, and might
> desugar to something like this:
>
> multi sub infix:<==>($left, $right, :$ok) {
>$*TEST_BACKEND.proclaim($left == $right, $ok)
>or $*TEST_BACKEND.diag(
>"Got: «$left.perl()»; Expected: «$right.perl»");
> }
>
> (Daniel Ruoso also proposed to call the adverb :test
> instead of :ok, making it easier to read but a bit
> longer; my happiness doesn't depend on the exact name,
> but of course we can discuss it once we have settled
> on this scheme, if we do so).
I like this idea and with it built into the language itself, there will be
much less of an excuse to skip testing. I like the adverb form, which seems
more perl6 than C. Naming it something like :test is a better idea than :ok
as that seems a bit more direct.
There isn't much in the spec concerning namespaces, other than the default *
namespace. Is there any reason why the testing framework can't go in it's
own namespace?
> * We nearly double the number of built-in operators
> by adding an :ok multi
> * We force implementors to handle operator adverbs
> and named arguments very early in their progress
> (don't know how easy or hard that is)
> * Testing of operators becomes somewhat clumsy. If you
> * want to test infix:<==>, you won't write
> '2 == 2 :ok("== works")', because you test a
> different multi there. Instead you'd have to write
> something like '?(2 == 2) :ok("== works")', where
> :ok is an adverb on prefix:.
>
These are mostly disadvantages to implementors, not users of the testing
framework. I'd rather the implementations struggle to implement a built-in
testing functionality than users of the language struggle to use the
built-in testing.
> I'll send another mail on the subject of pluggable
> testing backends in order to allow different emitters
> (TAP output, storage into databases, whatever)
This is a requirement for me. Having only TAP emitters may not integrate
well. It would be nice if the spec, if added, would allow flexibility in
this realm. I would actually like to see a flexible system that allowed me
to define a new emitter, say for the cases where you want to integrate perl6
testing into an existing testing framework (think automated builds and
tests).
-Jason "s1n" Switzer
Re: RFD: Built-in testing
On Tue, Jan 20, 2009 at 08:08:57PM +0100, Moritz Lenz wrote: : * We nearly double the number of built-in operators :by adding an :ok multi My feeling on this is that the compiler should simply hardwire this particular adverb so that all the tests can be autogenerated, and the multi system never needs to see those versions. We are merely hijacking the adverb syntax so that is clear which operator is being modified. There is no need for the late binding of multi. It's just a "reserved adverb" if you will. Which probably means it should be something unlikely to collide with user-defined adverbs. Maybe something in all caps. For what it's worth, :OK<> can be typed with one hand while the other holds down the shift key. :) Larry
RFD: Built-in testing
A few months ago Larry proposed to add some testing
facilites to the language itself, because we want to
culturally encourage testing, and because the test
suite defines the language, so we need to specify the
behaviour of our testing facilities anyway.
We also discussed some possible changes to the current
testing syntax, please read the IRC discussion starting
from here:
http://irclog.perlgeek.de/perl6/2008-10-09#i_613827
There are some problems with the current approach,
especially if we make it built-in:
* the word 'is' is overloaded in Perl 6, it is used
for traits (class A is rw { ... }),
implementation types (my @a is TiedArray) and
inheritance (class A { is B; ... }). Especially
the the last one can appear in the same position
as an is() test, and means something completely
different
* if we export subs is() and ok(), we clutter the
namespace with subs with short names - not very nice
* is() is rather imprecise; it doesn't say *how*
things are compared. Currently two options seem to
be open for the comparison semantics: either
string based, or deep structural equality (with
infix:). Both are very problematic: The
stringification of some structures can be
implementation specific (for example for Ranges),
and it often looses lot of information. Also pugs
used to stringify hashes in insertion order, but
that's not forced by the spec, so many tests
relied on that behaviour, ie they were wrong.
Comparison by infix: is dangerous, because it
is very strict, and things that were identical in
the early stages of the compiler become distinct
later on. Consider 'sub f { return 1, 2, 3}; say
f() eqv (1, 2, 3)'. Pugs says this is true,
because it doesn't implement return() as returning
a capture (or in turn thinks that lists are eqv to
captures), and testers would rely on this.
Future versions of a compiler would contradict the
previous results, and thus put an additional burden
on the test suite maintainers (ie mostly me). There
are other subtle distinctions (like between List
and Array) that make it hard to write tests
with infix: correctly.
So we want to get rid if the is() test function. The
current workaround is to use ok() and an explicit
comparison operator like this:
ok $x == 1e5, 'with explicit numeric comparison';
However this just tells us if a test fails, not how it
fails - it would be nice to have something like
Test::More's output "Expected 1e5, got 1e4". The only
way that ok() could produce such diagnostics would be
to declare it a macro that peeks into the AST of its
first argument and tries to find the two values. But
that's very advanced magic, and might not even be
possible in a DWIMmy way in the general case.
So Larry and Patrick developed the idea of creating an
adverb on the test operator instead:
$x == 1e5 :ok('the :ok makes this is a test');
This is an adverb on the infix:<==> operator, and might
desugar to something like this:
multi sub infix:<==>($left, $right, :$ok) {
$*TEST_BACKEND.proclaim($left == $right, $ok)
or $*TEST_BACKEND.diag(
"Got: «$left.perl()»; Expected: «$right.perl»");
}
(Daniel Ruoso also proposed to call the adverb :test
instead of :ok, making it easier to read but a bit
longer; my happiness doesn't depend on the exact name,
but of course we can discuss it once we have settled
on this scheme, if we do so).
So every operator that returns a boolean would get a
multi with the named argument :ok, which could be
autogenerated for most operators, but hand-written for
others that need more verbose diagnostics (for example
the smart match operator could tell you which of its
hundred possible comparisons it used). That's not just
limited to infix operators, ok($x, '$x is true') could
be written as ?$x :ok('$x is true'), where the :ok is
an adverb on prefix:;
This approach gives us
* good and easy diagnostics
* exactness by forcing the explicit choice of
comparison semantics
* nice integration into the Perl 6 syntax
* no cluttering of the namespace with short subs
However nothing in life is free, we pay for it with a
few disadvantages:
* We nearly double the number of built-in operators
by adding an :ok multi
* We force implementors to handle operator adverbs
and named arguments very early in their progress
(don't know how easy or hard that is)
* Testing of operators becomes somewhat clumsy. If you
* want to test infix:<==>, you won't write
'2 == 2 :ok("== works")', because you test a
different multi there. Instead you'd have to write
something like '?(2 == 2) :ok("== works")', where
:ok is an adverb on prefix:.
So I'd like to hear your opinions: do you think
adverb-based testing is a good idea? If you don't like
it, do you see any other good way to tackle the
problems I mentioned above?
I'll send another mail on the su
Re: New perl6 wiki
Oh,... i see. Fixed That! On 19 ene, 15:09, mor...@faui2k3.org (Moritz Lenz) wrote: > Hi, > > dev.null.box wrote: > > Yes, yes, i know. There is an official perl6 wiki. But, i think a more > > "friendly" wiki is needed, so i just started a new mediawiki one in > >http://perl6.wikia.com > > I appreciate your effort, and at the same time I'd like to ask you (and > your fellow contributor(s)) to actually test what you write, whenever > possible. For example onhttp://perl6.wikia.com/wiki/ArrayI found at > least three errors that could have easily been trapped by running the > examples in Rakudo (or pugs, for that matter). > > Cheers, > Moritz
Re: How do I help?
fREW Schmidt wrote: > I just recently read Ovid's post on use Perl about how we can help by > fixing PUGS tests. I was a little clear on what he meant and I am a > little anxious to do something. I checked out the code for parrot > already and I am getting the pugs code while I write this. Anyone > have any ideas for stuff that's easy enough for a regular old perl5 > guy to do but boring enough not to be done? Since the tests are all written in Perl 6, you have to learn at least a bit of the language. In the pugs repo there's a file in t/TASKS that contains a list of things to be done - maybe you can start there. In case of doubt join our IRC channel (irc.freenode.org/#perl6) and ask for guidance there. Cheers, Moritz
Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)
Darren Duncan wrote:
1. What we *should* be doing with the Prelude, like with STD.pm, is
write under the assumption that the implementation is also written in
Perl 6.
We should write the Prelude in as declarative a manner as possible,
saying *what* we want to happen rather than how, such as you do when
writing in a functional language.
We should make use of Perl's higher-level tools like hyper-operators and
reduce-operators etc and write in a fashion that is developer focused,
same as writing normal Perl 6.
I do agree that a prelude.pm should be written atas higher level as
possible, but I would not that Perl6 is not a "declarative" language.
Using the most powerful operators available (I'd like to see more of
them) is about the best you can do: as soon at you start using
codeblocks to define things, you get beyond the realm where compile-time
analysis is possible in a dynamic language.
Lets imagine I want to define a "sqrt($x)" function in a declarative
style in perl6 (and lets image we've defined a Real type with
Real::Epsilon being the precision of the representation). The
declarative version of sqrt must say to find a value within the set of
Real numbers that, when squared, is closest to $x:
sub sqrt(Num where { 0 <= $_ <= Real::Max } $x) {
(0..$x/2 :by(Real::Epsilon)).min: { abs $x - $^candidate ** 2 }
}
(This assumes that Array::min will one day accept a code-block, just
like grep, to define the property of the input list to be minimized).
The code would give a correct answer (the positive sqrt), and is written
as a fairly direct implementation of the declarative formulation. What
I'm not so sure of is that it would be a good way to write prelude.pm:
running the test suite would probably take quite a while.
So do you really mean "as declarative a manner as possible"? Or would
you consider this example to go beyond "possible"?
Re: New perl6 wiki
Hi, dev.null.box wrote: > Yes, yes, i know. There is an official perl6 wiki. But, i think a more > "friendly" wiki is needed, so i just started a new mediawiki one in > http://perl6.wikia.com I appreciate your effort, and at the same time I'd like to ask you (and your fellow contributor(s)) to actually test what you write, whenever possible. For example on http://perl6.wikia.com/wiki/Array I found at least three errors that could have easily been trapped by running the examples in Rakudo (or pugs, for that matter). Cheers, Moritz
Re: How do I help?
> Since the tests are all written in Perl 6, you have to learn at least a > bit of the language. I figured that; I just wanted to start off with perl6 before I did anything in PIR. > In the pugs repo there's a file in t/TASKS that contains a list of > things to be done - maybe you can start there. In case of doubt join our > IRC channel (irc.freenode.org/#perl6) and ask for guidance there. I'll see if I can take care of some of these. The one that looks like I could learn a lot from and definitely do is the one where you test builtin functions with named parameters as most of these having been tested that way yet. I hope it helps! -- -fREW
