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

Multiple implementations of Perl 6

3 views
Skip to first unread message

Andrew Savige

unread,
Dec 24, 2005, 7:25:43 AM12/24/05
to perl6-l...@perl.org
Apologies if I'm Mr Magoo, but I did a bit of a search on this just now, and
uncovered little more than a pithy quote from Piers Cawley in:

http://dev.perl.org/perl6/list-summaries/2005/p6summary.2005-07-05.html

asserting that "Multiple implementations are good, m'kay".

If anyone can point me to where this is discussed in the official Perl 6 docs,
I would be grateful.

I'm curious to know if the Perl 6 design team fully endorse a change from the
Perl 5 "the (single) implementation *is* the specification" model to a
"multiple implementations are good, m'kay, but from a single (detailed and
precise) specification" model.

Thanks,
/-\


Send instant messages to your online friends http://au.messenger.yahoo.com

Ævar Arnfjörð Bjarmason

unread,
Dec 24, 2005, 1:48:56 PM12/24/05
to Andrew Savige, perl6-l...@perl.org
On 12/24/05, Andrew Savige <ajsa...@yahoo.com.au> wrote:
> I'm curious to know if the Perl 6 design team fully endorse a change from the
> Perl 5 "the (single) implementation *is* the specification" model to a
> "multiple implementations are good, m'kay, but from a single (detailed and
> precise) specification" model.

They sure do, one of the big changes in Perl 6 is that there actually
is a specification, as opposed to a reference implementation that
serves as the spec. If perl is behaving differently than the spec says
it should perl will be changed, not the spec (as might have been the
case with <6 and its documentation).

There's no reason for why multiple implementations wouldn't be a good
thing™. Lots of other languages have multiple implementations, why not
Perl?

Larry Wall

unread,
Dec 24, 2005, 1:40:18 PM12/24/05
to perl6-l...@perl.org
On Sat, Dec 24, 2005 at 11:25:43PM +1100, Andrew Savige wrote:
: Apologies if I'm Mr Magoo, but I did a bit of a search on this just now, and

: uncovered little more than a pithy quote from Piers Cawley in:
:
: http://dev.perl.org/perl6/list-summaries/2005/p6summary.2005-07-05.html
:
: asserting that "Multiple implementations are good, m'kay".
:
: If anyone can point me to where this is discussed in the official Perl 6 docs,
: I would be grateful.

Hmm, don't recall such a spot offhand.

: I'm curious to know if the Perl 6 design team fully endorse a change from the


: Perl 5 "the (single) implementation *is* the specification" model to a
: "multiple implementations are good, m'kay, but from a single (detailed and
: precise) specification" model.

I think the design team would probably agree with me that you've
set up a bit of a false dichotomy there. Either of those extremes
is basically unworkable for what we want to do. We've found from
Perl 5 that the single implementation strategy has its limits.
But we also recognize that the Perl community is not (and cannot be)
well-organized enough in the industrial sense to write a complete
specification. (Plus I personally don't feel that anyone is smart
enough to write a complete spec for the sort of evolvable thing
we want. In this case Intelligent Design comes out to being the
same thing as Darwinism.)

So in the typical Perl community fashion, we're evolving an
intermediate solution that lets us have our cake and eat it too.
Pugs is becoming our reference implementation, and our hope is that
the test suite we're evolving essentially becomes the design spec.
On the other hand, Pugs is by design not going to be "the" production
version, because the Pugs project is optimized for fun, and any
pumpking will tell you that maintaining a production version is not
always fun. So we know that there will multiple implementations.
We fondly hope that Parrot will be the first among equals, but we're
not putting all our eggs in one basket.

Likewise Parrot is targeting Perl as its "first" language, but if you
look at recent history you'd think they were mainly targeting TCL.
And that's fine by us, both officially and unofficially.

In short, we know exactly what we're not doing, :-)

Larry

0 new messages