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

Regarding status of Parrot and pure perl Perl6 compiler

3 views
Skip to first unread message

Millsa Erlas

unread,
Mar 9, 2005, 6:34:07 PM3/9/05
to perl6-i...@perl.org
What is the current status of the development of the Parrot and the Perl
6 compiler written in Perl? I hope that producing a Perl 6 compiler
written in Perl 6 and the Parrot VM is still a high priority and is
being actively developed as the premier compiler and VM for the Perl 6
language. A Perl 6 compiler written in Perl 6 I believe is an extremely
useful and essential component since it will allow Perl programmers to
participate and assist in the development of the Perl 6 compiler. Also
where is the CVS/SVn repisitory for Perl6 compiler kept these days?

Also, what is the status of Ponie and providing complete
interoperability between Perl 5 language and documented XS support and
Parrot and Perl 6? I believe that assuring that all Perl 5 language code
and all XS code that follows the documented interfaces can be called
from Perl 6 and vice versa is extremely important and should be taken
seriously. There is a very large body of Perl 5 code and modules and it
should remain possible to continue to use them all from Perl 6, and for
Perl 5/Ponie to be able to use all Perl 6 modules, so both Perl 5 and
Perl 6 can leverage a shared base of modules and leverage the momentum
of each others module base and so programs can be written in a hybrid of
both Perl 5 and Perl 6 modules. Hopefully it is obvious that the large
and rich library of Perl 5 modules needs to be retained and reused on
Perl 6, since it would be impractical and innefficient to rewrite them
all in Perl 6, and also that Perl 5 programs need to be able to benefit
from new Perl 6 modules.

Thank you for you attention to this letter, and keep up the great work.

Markus Laire

unread,
Mar 10, 2005, 7:53:59 AM3/10/05
to Millsa Erlas, perl6-i...@perl.org
Millsa Erlas wrote:
> What is the current status of the development of the Parrot and the Perl
> 6 compiler written in Perl? I hope that producing a Perl 6 compiler
> written in Perl 6 and the Parrot VM is still a high priority and is
> being actively developed as the premier compiler and VM for the Perl 6
> language. A Perl 6 compiler written in Perl 6 I believe is an extremely
> useful and essential component since it will allow Perl programmers to
> participate and assist in the development of the Perl 6 compiler. Also
> where is the CVS/SVn repisitory for Perl6 compiler kept these days?

I've been following the development of pugs (http://pugscode.org/), so I
can give a short answer based on that.

While pugs is currently written in Haskell, roadmap does mention the
idea to eventually port pugs to perl6 if needed, which would give us a
Perl 6 compiler written in Perl.
(see http://svn.perl.org/perl6/pugs/trunk/docs/01Overview.html)

The "if needed" means, I'd guess, that if no other implementation of
perl6 compiler written in perl exists at that time, we can get one from
the pugs project.


About the status of pugs-project: Pugs is currently approaching first
milestone 6.2. Because this project is still so new, it's quite
impossible to give any estimates about any further milestones. (And
porting pugs to Perl6 is the final milestone v6.283185)

I think that after few months of development, we should have a lot
better picture of how quickly pugs-project can continue to implement the
various features perl6-language requires.

And of course we will eventually need working Parrot to compile perl6
into a Parrot-code, but I don't know much about that as I'm currently
mainly interested about the development of pugs-project.

--
Markus Laire
<Jam. 1:5-6>

Millsa Erlas

unread,
Mar 10, 2005, 4:14:55 PM3/10/05
to perl6-i...@perl.org
Markus Laire wrote:

>
>
> I've been following the development of pugs (http://pugscode.org/), so I
> can give a short answer based on that.
>
> While pugs is currently written in Haskell, roadmap does mention the
> idea to eventually port pugs to perl6 if needed, which would give us a
> Perl 6 compiler written in Perl.
> (see http://svn.perl.org/perl6/pugs/trunk/docs/01Overview.html)
>
> The "if needed" means, I'd guess, that if no other implementation of
> perl6 compiler written in perl exists at that time, we can get one from
> the pugs project.

Thank you for your reply. I am glad that this Perl 6 compiler has been
implemented indeed. It will be good for many purposes, both to test the
Perl 6 language and provide a bootstrap for a compiler written in Perl 6
itself ( I was wondering how they were going to bootstrap the
language), and for using and getting a feel for the language while the
architecture continues to be developed. Certianly I appreciate it.


>
> And of course we will eventually need working Parrot to compile perl6
> into a Parrot-code, but I don't know much about that as I'm currently
> mainly interested about the development of pugs-project.
>

Yes, we will want to be able to run Perl 6 on top of Parrot, and also
allow Perl 5 modules to be used with Perl 6 modules and vice versa. I
have written a lot of code in Perl 5 and I would like to be able to call
it from Perl 6, and also be able to call Perl 6 code I write from Perl
5. Parrot is a pretty important project, as well as Ponie.

Nicholas Clark

unread,
Apr 6, 2005, 8:50:41 AM4/6/05
to Millsa Erlas, perl6-i...@perl.org, poni...@perl.org

On 9 Mar 2005, at 23:34, Millsa Erlas wrote:

> Also, what is the status of Ponie and providing complete
> interoperability between Perl 5 language and documented XS support and
> Parrot and Perl 6? I believe that assuring

For various internal and external reasons work has been pretty much
stalled for quite a while. I'm pleased to announce that it's now able
to restart, and that I'm going to be able to allocate about 1 to 1½
days per week to it on average.

There is now a detailed roadmap breaking down the tasks needed between
here and a first release, with estimates of times. It's checked into
CVS at the top level, and available online as
http://opensource.fotango.com/software/ponie/plan

The roadmap starts with an introduction to Ponie, gives instructions on
how to check it out of CVS and build it, and other useful information,
so I'll avoid duplicating its contents here.

Ponie is using released versions of Perl 5.9.x, rather than tracking
the day to day core perl development. As Rafael released 5.9.2 last
week, on Monday I updated Ponie's source to 5.9.2. Given that Ponie has
made quite a lot of changes to odd parts of the Perl source, and there
has been a lot of core Perl development since 5.9.1, this upgrade was
never going to be trivial. In the end it took a the whole day of hard
work, but it seems to be working now. ["You are in a twisty maze of CVS
conflicts, all alike". :-( Banging my head trying to work out why
ExtUtils::MakeMaker is ignoring miniperl. etc]

Nicholas Clark

Millsa Erlas

unread,
Apr 6, 2005, 10:39:18 AM4/6/05
to perl6-i...@perl.org, poni...@perl.org


That is great to hear. The interoperability of Perl 6 and Perl 5 and
vice versa is very important. For instance, if someone writes something
in Perl 6, they will want to be able to take advantage of the rich set
of Perl 5 modules avialable, and if you are writing code in Perl 5, they
will want to be able to access Perl 6 modules. This allows Perl 6 and
Perl 5 to share the same module community and share the same inertia in
terms of module selection and diversity. This will also allow needless
duplication of modules to be avoided, since both perl 5 and Perl 6 would
be able to use the same modules. There is a large library of Perl 5
modules and that library needs to be retained into Perl 6, especially to
assure the versatility and useability of Perl that comes from the large
collection of modules is avialable to both languages.

Thank you.

Leopold Toetsch

unread,
Apr 6, 2005, 11:18:12 AM4/6/05
to poni...@perl.org, perl6-i...@perl.org
Nicholas Clark <ncl...@fotango.com> wrote:

> http://opensource.fotango.com/software/ponie/plan

Wow, great detailed plan.

Some remarks:

1) objects seem to be missing

Parrot is much more object oriented then Perl5. The Perl5 "magic" that
depends on custom vtable is basically the task of creating a new class.
See below a rough Parrot program [1] that implements tie and overload
(somehow :)

For interoperbility I think that we need some more ParrotClass PMCs:

- the current is very similar to a perl5 blessed array, except it's
array size is fix
- a hash based one - similar to Python objects and of course Perl5
- scalar blessed can probably be done like below in [1]
- and eventually one that's based on a C structure, i.e. that abstracts
the {Un,}ManagedStruct PMCs.

2) a lot of Parrot (mostly) vtable methods are missing

We got tons of vtables and MMD methods with native types, but PMC
variants are missing. E.g. simple things like C<get_string> or
C<get_numeric> - we have a native C<get_string> which should be called
C<get_string_native>. Most of the string opcodes are just available as
native STRING variants too.

I've already proposed to split the vtable into various parts
("interfaces") so that not all PMCs take the penalty of having the full
vtable size all the time.

3) Parrot STRINGs

All the native types are mostly unusable for Perl5, Python,.... Only
Perl6 has a notion for native types. A String PMC is just a wrapper
around such a STRING PObj and adds one indirection to all string access,
that's not good.

OTOH a STRING is not a lightweight or thin structure, just the opposite
of it, its' much bigger then a PMC. The discussion "String theory" on p6l
has shown that Perl6 has a more low-level concept of the C<str> native
type - more something like a plain C string, w/o unicode support.

STRINGs are unusable with multi-threaded Parrot as the String PMC has to
properly lock the STRING, the STRING itself can't do that.

This leads directly to:

4) PMC structure

PMCs are too rigid: Either too big (e.g. Integer) or too small for more
complex types like subroutines or aggregates. The fixed size restriction
either forces wastage of space or additional indirections. I'd like to
have a PMC layout that's much more the layout of Perl5: a fixed and
possibly small header and, if upgraded, an additional body.
This means (current STRING + vtable) := String PMC.

5) dunno, but switching lexicals to Parrot seems to be late in the plan.
Needs IMHO be done, when running Parrot opcodes.

> Nicholas Clark

leo

[1]
$ cat tie.imc

.sub main @MAIN
.local pmc d, l, r, cl, _add
cl = subclass "Integer", "AInt"
d = new "AInt"
l = new "AInt"
r = new "AInt"
l = 3
r = 39
print l
print "\n"
print r
print "\n"
add d, l, r
print d
print "\n"
_add = find_global "AInt", "__add"
$I0 = typeof cl
.include "mmd.pasm"
mmdvtregister .MMD_ADD, $I0, $I0, _add
l = r + d
print d
print "\n"
.end

.namespace ["AInt"]
.sub __add # @MULTI(AInt, Aint) - not yet
.param pmc l
.param pmc r
.param pmc d
print "in add\n"
$I0 = l
$I1 = r
$I2 = $I0 + $I1
d = $I2
.end

.sub __get_integer method # __get_numeric
print "FETCH\n"
$P0 = getattribute self, "AInt\0__value"
$I0 = $P0
.return ($I0)
.end

.sub __set_integer_native method # __set_integer
.param int v
print "STORE\n"
$P0 = getattribute self, "AInt\0__value"
$P0 = v
.return ($I0)
.end
$ ./parrot tie.imc
STORE
STORE
3
39
42
in add
FETCH
FETCH
STORE
42

0 new messages