I do not believe that it would be a good idea to mix perl5 and perl6 on
any of the lists. If something is useful to perl5 send it on to p5p.
Anything else just confuses the issues.
If you'd like a set of throw-away tests. That will be replaced with
the formal spec. (Which may of course be the regression tests.)
For the interim to iron out the kinks in qa. Great.
One of my pet peeves is the amount of edge cases (or at least my lack
of knowledge) that is involved. Having a formal spec if nothing more
that documented edge cases, will be fine.
<chaim>
>>>>> "MGS" == Michael G Schwern <[EMAIL PROTECTED]> writes:
MGS> On Wed, Jul 26, 2000 at 08:51:18PM -0400, Chaim Frenkel wrote:
>> I'd like to reject the philosophy. I'd prefer that the language define
>> perl. I.e. not an implementation. Rather the spec.
>>
>> Shouldn't the tests be designed from the spec?
MGS> Spec? What spec? Perl has a spec?
MGS> At the moment, Perl has no formal specification. Perl doesn't even
MGS> have an informal specification. The existing regression suite is very
MGS> incomplete. The documentation is also incomplete and in some cases
MGS> wrong. The auto-generated API docs are also incomplete. I'm not
MGS> complaining, I'm just stating facts.
MGS> There is currently NO WAY for anyone to rewrite perl5 and know that
MGS> their implementation is complete. This is what I mean by the
MGS> regression tests becoming a spec. By applying a test to every patch
MGS> you have a test for every language feature, every internal function
MGS> and every statement asserted by the documentation. You then have a
MGS> way to verify that perl is perl.
MGS> Now, if Perl 6 decides it wants a formal spec then that's just hoopy
MGS> with me. However, we will treat it like any other set of
MGS> documentation and write tests for it. (In fact, we could probably
MGS> automate it.) That particular testing suite would be applied to
MGS> alternative implementations to verify their accuracy.
--
Chaim Frenkel Nonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
