Perl 6 compiler written in Perl 6, Ponie are important for users

13 views
Skip to first unread message

Millsa Erlas

unread,
Jun 26, 2005, 3:46:21 PM6/26/05
to perl6-c...@perl.org

Being a Perl 5 user myself, I believe that it would be the best idea to
write the final Perl 6 compiler targetting Parrot ideally in Perl 6 or
at least some other higher-high level language such as Haskell. The
reason behind this is this would allow the compiler to be maintained by
Perl 6 developers who do not have a lot of experience with lower-high
level or medium level languages such as C/C++ or PIR/IMC. I believe a
Perl 6 compiler written in C would be a bad idea and would in fact
repeat one of the major problems with Perl 5. It would lock out Perl
developers (like me) who do not know C from being able to understand and
improve upon the compiler. C is not an easy language for many to use or
learn and there are many people who are not proficient in it. C for me
and many Perl developers is not a pretty or a pleasant language to deal
with.

A self-hosting Perl 6 will require of course an implementation of Perl 6
in another language. Pugs seems to be quite far ahead in this respect,
quite a bit has already been accomplished with Pugs so it would seem to
me to be most efficient and quick to turn Pugs into a Parrot targetting
compiler.

Sure, Perl 6 being self hosting will require a previous version of Perl
6 to compile the new version. But I really dont see this as a problem,
many other languages are self hosting, like C, where the exact same
thing is done. I just dont think its a problem at all. It is a
reasonable trade-off for having a compiler that is eisier to read,
understand, debug, and which can be read and improved
by the same Perl community that uses it, which I think is essential.

I believe, in order for Perl 6 and Parrot to be more widely used, needed
is a fully functional Perl 6 compiler targetting Parrot, and the Ponie
project to allow all existing Perl 5 and XS modules to be accessed from
Perl 6 and for Perl 6 modules to be accessed from Perl 5. Perl 5 and
Perl 6 should be able to co-exist alongside each other, sharing the same
library of modules, and being able to use modules written in either
language, or XS. This is essential, and quite important, and the most
efficient thing to do, since the work done on existing Perl 5 modules,
including XS ones, would not need to be duplicated, and people would be
able to use the full collection of Perl 5 and XS libraries with Parrot,
Perl 5 and Perl 6, which is one of the things that I need, and I suspect
most people need, to be able to start using Parrot and Perl 6, and
prevents needless duplication of the same functionality in multiple
languages. Once Ponie is completed, new versions of Perl 5 could use the
Parrot VM, and Perl 5 and Perl 6 would be able to share the same Parrot VM.

I believe Ponie and a Parrot targetting Perl 6 compiler (Pugs
initially), is probably one of the most important and essential parts of
Parrot and Perl 6 and getting these into a useable state as soon as
possible.

Jonathan Worthington

unread,
Jun 27, 2005, 10:27:34 AM6/27/05
to perl6-c...@perl.org
"Millsa Erlas" <millu...@yahoo.com> wrote:
> A self-hosting Perl 6 will require of course an implementation of Perl 6
> in another language. Pugs seems to be quite far ahead in this respect,
> quite a bit has already been accomplished with Pugs so it would seem to
> me to be most efficient and quick to turn Pugs into a Parrot targetting
> compiler.
>
Pugs already is targetting Parrot, though the compiler can't, as far as I'm
aware, emit PIR to do all that the Pugs evaluator can yet. :-)

See also some of the recent-ish postings in Autrijus' journal, which may be
of interest.
http://use.perl.org/~autrijus/journal/

Jonathan

per...@warpmail.net

unread,
Jun 27, 2005, 10:47:52 AM6/27/05
to perl6-c...@perl.org
So are you suggesting that Ponie be written in Perl 6 or Perl 5? If you
want to remain consistent with the self hosting approach and maximize
the Perl 5 userbase, the Ponie compiler Perl should be written in Perl
5, and thus self hosted as well via itself on Parrot. If this were the
case, work on bootstrapping Ponie in Perl 5 could begin now.

Norman Nunley

unread,
Jun 27, 2005, 12:08:45 PM6/27/05
to per...@warpmail.net, perl6-c...@perl.org

On 27 Jun 2005, at 15:47, per...@warpmail.net wrote:
> So are you suggesting that Ponie be written in Perl 6 or Perl 5?
> If you

Ponie is being written in C. As it stands, it's a refactoring of the
current perl code base to
use Parrot internals. When all the intended changes have finished,
it will still have a C core that compiles Perl code to Parrot bytecode.


> want to remain consistent with the self hosting approach and maximize
> the Perl 5 userbase, the Ponie compiler Perl should be written in Perl
> 5, and thus self hosted as well via itself on Parrot. If this were
> the
> case, work on bootstrapping Ponie in Perl 5 could begin now.


While it would be an interesting exercise to bootstrap Perl 5 in Perl
5, it is by no means the
simplest way of making things work. The stated goal for Ponie is to
ensure an easy transition
from Perl 5 to the Parrot (and Perl 6) world. If you were simply to
throw out the existing
implementation, there's a good chance that you'd mess up bindings to
XS and other
evil assumptions that CPAN core module writers made.

Oh, and work has already begun on Ponie, as can be seen in the
archived posts on http://www.nntp.perl.org/group/perl.ponie.dev/

Norman


Millsa Erlas

unread,
Jun 28, 2005, 10:56:31 AM6/28/05
to perl6-c...@perl.org
Per...@Warpmail.Net wrote:
> So are you suggesting that Ponie be written in Perl 6 or Perl 5? If you
> want to remain consistent with the self hosting approach and maximize
> the Perl 5 userbase, the Ponie compiler Perl should be written in Perl
> 5, and thus self hosted as well via itself on Parrot. If this were the
> case, work on bootstrapping Ponie in Perl 5 could begin now.
>

No, not at all. I personally dont think it would be a good idea or a
wise use of time to make Perl 5 self hosting. One goal of Ponie is to
maintain support with XS and embedding. This involves the perl internals
APIs and XS, which are implemented and accessed at the C level. Part of
the existing Perl 5 internals code base is simply being ported over to
and wrapped around Parrot, as I understand it. this is to maintain
compatability with the complex and peculiar XS and Perl internals APIs,
this is the best way to maintain compatability with XS and Perl modules.

I further said it would be nice to have *Perl 6* self-hosting
*eventually*. Although, Pugs as a Perl 6 compiler would be sufficient
initially until a Perl 6 one can be written. The most important thing is
to have a Perl 6 implementation to use, although I believe it is good
that it is being written in a high level language like Haskell, rather
than a medium level one like C.

Perl 5 will still be around via Ponie, but i suspect most major new perl
language features are being implemented on Perl 6, this will be the
platform for adding new perl language features to and extended Perl
further. So it makes sense to make Perl 6 compiler easily readable by
the same developers who use it, by making it self hosting. For me, that
is the benefit of having it self hosting. I dont think that it would be
a valuable use of time to make Perl 5 self hosting, requiring a major
rewrite of it, when Perl 6 is the platform where major new language
features will be implemented. Ponies method of refactoring the Perl 5 C
code fits the goal well, which is to provide support for existing Perl 5
language XS, internals and language, on Parrot, but not necessarily a
platform for implementing major new language features (but who knows,
someone still could add some new features to the Ponie C source).

Patrick R. Michaud

unread,
Jul 2, 2005, 12:51:40 PM7/2/05
to Millsa Erlas, perl6-c...@perl.org
On Sun, Jun 26, 2005 at 03:46:21PM -0400, Millsa Erlas wrote:
>
> Being a Perl 5 user myself, I believe that it would be the best idea to
> write the final Perl 6 compiler targetting Parrot ideally in Perl 6 or
> at least some other higher-high level language such as Haskell.

There's been a fair amount of confusion expressed about the implementation
of the "final" Perl 6 compiler, especially with regards to the language
that it will be implemented in.

First, it's not clear that there will be, or even needs to be,
a "final" Perl 6 compiler, any more than any other language is
limited to having a single compiler. Multiple implementations
can be good; different compilers can emphasize different aspects of the
whole process, such as execution efficiency, stability, development
efficiency, enhancement, etc. What we're aiming for now is to
work to a 6.0.0 release, but even after such a release it's always
possible that the compiler implementation details could change
substantially in subsequent releases.

Second, I don't believe that we're at a point where making
a declaration or decision on this issue is of critical importance
to development. We're developing not just a compiler, but also
tools and an environment to support other languages and
language interoperability. Thus from a "whole product" perspective,
there are audiences and needs that must be addressed in addition
to those of Perl 6 compiler authors, e.g., for those who might
wish to use Parrot for things not directly related to Perl 6.

But most importantly, I think I can say with some certainty
(because it's a design feature of Perl 6) that whatever compiler
architecture and implementation we end up with will by design be
very accessible and understandable to Perl 6 programmers without
requiring a deep knowledge of low-level details such as Parrot,
PASM, or PIR. If we want to make it possible for Perl 6 programmers
to tweak and extend the language, it makes sense to have a compiler
that is understandable in terms of the language*s* those programmers
speak. And by "languages" I'm alluding to the fact that Perl 6
has a number of special-purpose languages within it (the rules
syntax being a prime example), so I believe it's very likely that
we'll have still more special-purpose languages and tools for
compiler development, most if not all of which will be readily
understandable and tweakable by Perl 6 programmers.

So, the language and specific tools to be used for the
implementation of a "final" compiler is not something I'm
really concerned with at this point. AFAIK the Perl motto continues
to be "There's More Than One Way To Do It", and this probably holds
true for the Perl 6 compiler implementation as well. We know of
some things that must be present in the compiler, and some things
that ought to be avoided, and within those constraints there's
still a lot for us to explore and discover before we come up with
*the* 6.0.0 release of Perl (which necessarily includes more than
just a compiler).

Pm

Reply all
Reply to author
Forward
0 new messages