Working on punie + rindolf (the implementation) Reloaded

0 views
Skip to first unread message

Shlomi Fish

unread,
Mar 30, 2007, 2:32:28 PM3/30/07
to Allison Randal, perl5-...@perl.org
Hi Allison!

I've been thinking that after the death of PONIE, I'll try to bring perl 5 to
Parrot from a different approach. Why not write a Perl 5 front end that will
compile Perl 5 code to Parrot (or other languages)? I could use PPI or a
different Perl 5 parser to facilitate doing it, etc., and naturally writing a
compiler in Perl 5 is much easier than in C.

And we'll also get C-hosting and self-hosting with that.

I'd like to call it "rindolf" (with a lowercase "r") after
http://www.shlomifish.org/rindolf/ , where rindolf 1.0 will implement Perl
5.8.x completely. When and after we're done implementing all the perl5's (the
implementation) features, we'll perhaps extend the language with more
functionality, either derived from Perl 6 or as dimmed appropriate for "the
language once known as Perl 5".

What I want to ask is about punie - is this a good basis? I know Perl 5 is
still mostly backwards-compatible with Perl 1, so I might be able to make use
of punie. But I'm not sure if it's worth the trouble.

Secondly, should I use svk (which I'm still finding a bit confusing) or can I
have a commit access to the Parrot svn repository?

All of this is subject to:

<<<<<<<<<<<<
Rule of Open-Source Programming #11:

When a developer says he will work on something, he or she means
"maybe".
>>>>>>>>>>>>

Regards,

Shlomi Fish

---------------------------------------------------------------------
Shlomi Fish shl...@iglu.org.il
Homepage: http://www.shlomifish.org/

If it's not in my E-mail it doesn't happen. And if my E-mail is saying
one thing, and everything else says something else - E-mail will conquer.
-- An Israeli Linuxer

Allison Randal

unread,
Mar 30, 2007, 7:11:42 PM3/30/07
to Shlomi Fish, perl5-...@perl.org
Shlomi Fish wrote:
> Hi Allison!
>
> I've been thinking that after the death of PONIE, I'll try to bring perl 5 to
> Parrot from a different approach. Why not write a Perl 5 front end that will
> compile Perl 5 code to Parrot (or other languages)? I could use PPI or a
> different Perl 5 parser to facilitate doing it, etc., and naturally writing a
> compiler in Perl 5 is much easier than in C.
>
> And we'll also get C-hosting and self-hosting with that.
>
> I'd like to call it "rindolf" (with a lowercase "r") after
> http://www.shlomifish.org/rindolf/ , where rindolf 1.0 will implement Perl
> 5.8.x completely. When and after we're done implementing all the perl5's (the
> implementation) features, we'll perhaps extend the language with more
> functionality, either derived from Perl 6 or as dimmed appropriate for "the
> language once known as Perl 5".

It's an unusual approach. I have doubts about the particular
implementation plan, but I'd at least be interested to see how far you
get and what obstacles and successes you encounter along the way.

> What I want to ask is about punie - is this a good basis? I know Perl 5 is
> still mostly backwards-compatible with Perl 1, so I might be able to make use
> of punie. But I'm not sure if it's worth the trouble.

Punie will be the basis of one implementation of Perl 5 on Parrot. The
advantage of Punie is that it uses the Parrot compiler tool suite, which
provides powerful parsing capabilities (thanks to Perl 6 rules) and
powerful syntax tree transformation capabilities. It's light-years ahead
of writing a compiler in C (or Perl). But, since you don't plan to use
these tools, and plan to write your own parser and compiler, I don't see
that you'd be able to use much from Punie.

> Secondly, should I use svk (which I'm still finding a bit confusing) or can I
> have a commit access to the Parrot svn repository?

Commit access to Parrot is determined on a merit basis. The more
valuable patches you contribute to Parrot, and the more you demonstrate
an understanding of its internals, the more likely you are to be
considered for commit access.

We ultimately intend for most languages to be developed outside the
Parrot tree and distributed as separate loadable modules, so it makes
the most sense to set up your own subversion repository anyway.

> All of this is subject to:
>
> <<<<<<<<<<<<
> Rule of Open-Source Programming #11:
>
> When a developer says he will work on something, he or she means
> "maybe".

Of course.

Allison

Shlomi Fish

unread,
Mar 30, 2007, 10:17:32 PM3/30/07
to Allison Randal, perl5-...@perl.org
Hi!

On Saturday 31 March 2007, Allison Randal wrote:
> Shlomi Fish wrote:
> > Hi Allison!
> >
> > I've been thinking that after the death of PONIE, I'll try to bring perl
> > 5 to Parrot from a different approach. Why not write a Perl 5 front end
> > that will compile Perl 5 code to Parrot (or other languages)? I could use
> > PPI or a different Perl 5 parser to facilitate doing it, etc., and
> > naturally writing a compiler in Perl 5 is much easier than in C.
> >
> > And we'll also get C-hosting and self-hosting with that.
> >
> > I'd like to call it "rindolf" (with a lowercase "r") after
> > http://www.shlomifish.org/rindolf/ , where rindolf 1.0 will implement
> > Perl 5.8.x completely. When and after we're done implementing all the
> > perl5's (the implementation) features, we'll perhaps extend the language
> > with more functionality, either derived from Perl 6 or as dimmed
> > appropriate for "the language once known as Perl 5".
>
> It's an unusual approach. I have doubts about the particular
> implementation plan, but I'd at least be interested to see how far you
> get and what obstacles and successes you encounter along the way.
>

See below.

> > What I want to ask is about punie - is this a good basis? I know Perl 5
> > is still mostly backwards-compatible with Perl 1, so I might be able to
> > make use of punie. But I'm not sure if it's worth the trouble.
>
> Punie will be the basis of one implementation of Perl 5 on Parrot. The
> advantage of Punie is that it uses the Parrot compiler tool suite, which
> provides powerful parsing capabilities (thanks to Perl 6 rules) and
> powerful syntax tree transformation capabilities. It's light-years ahead
> of writing a compiler in C (or Perl). But, since you don't plan to use
> these tools, and plan to write your own parser and compiler, I don't see
> that you'd be able to use much from Punie.

Actually my intention is bringing Perl 5 to Parrot one way or another. If
punie will do it - that would be nice. Note that I was under the impression
that punie will be exculisevely for Perl 1, and not more. But I may have been
more.

I dare say punie suffers from a very bad name. People think it's a toy
compiler/interpreter.

>
> > Secondly, should I use svk (which I'm still finding a bit confusing) or
> > can I have a commit access to the Parrot svn repository?
>
> Commit access to Parrot is determined on a merit basis. The more
> valuable patches you contribute to Parrot, and the more you demonstrate
> an understanding of its internals, the more likely you are to be
> considered for commit access.

Fair enough. Of course, you may wish to look at the beginning of:

http://www.ussg.iu.edu/hypermail/linux/kernel/0703.3/1296.html

for some examples why being liberal on commit bits can be a good thing.

>
> We ultimately intend for most languages to be developed outside the
> Parrot tree and distributed as separate loadable modules, so it makes
> the most sense to set up your own subversion repository anyway.
>

Oh, I see. Does it mean I'm going to fork the punie code into rindolf in a
separate repository, using svk or whatever? Subversion cannot really handle
it well.

> > All of this is subject to:
> >
> > <<<<<<<<<<<<
> > Rule of Open-Source Programming #11:
> >
> > When a developer says he will work on something, he or she means
> > "maybe".
>
> Of course.

:-)

Allison Randal

unread,
Mar 31, 2007, 12:35:58 AM3/31/07
to Shlomi Fish, perl5-...@perl.org
Shlomi Fish wrote:
>
> Actually my intention is bringing Perl 5 to Parrot one way or another. If
> punie will do it - that would be nice. Note that I was under the impression
> that punie will be exculisevely for Perl 1, and not more. But I may have been
> more.

Punie is Perl 1. But as you observed, Perl 1 is a healthy subset of the
parsing requirements for Perl 5.

> I dare say punie suffers from a very bad name. People think it's a toy
> compiler/interpreter.

Never underestimate the power of being underestimated.

> Fair enough. Of course, you may wish to look at the beginning of:
>
> http://www.ussg.iu.edu/hypermail/linux/kernel/0703.3/1296.html
>
> for some examples why being liberal on commit bits can be a good thing.

Hmmmm... that's a thread that could have been started with more
diplomacy. :)

I generally find that the people with the greatest dislike of a waiting
period for commit access are the ones with the greatest need of a
waiting period for commit access.

> Oh, I see. Does it mean I'm going to fork the punie code into rindolf in a
> separate repository,

If you want to. I would suggest instead first learning how the Punie
code works, then adding a feature to the Punie code as a patch, or maybe
even a few features. At that point you'll be in a better position to
know if you really need a fork, or if it's better to just carry your
gained knowledge and experience to a new task.

Have you considered the fact that with the Parrot compiler tools you
could implement your rindolf spec directly without first implementing
Perl 5?

Allison

Shlomi Fish

unread,
Mar 31, 2007, 1:43:20 AM3/31/07
to Allison Randal, perl5-...@perl.org
On Saturday 31 March 2007, Allison Randal wrote:
> Shlomi Fish wrote:
> > Actually my intention is bringing Perl 5 to Parrot one way or another. If
> > punie will do it - that would be nice. Note that I was under the
> > impression that punie will be exculisevely for Perl 1, and not more. But
> > I may have been more.
>
> Punie is Perl 1. But as you observed, Perl 1 is a healthy subset of the
> parsing requirements for Perl 5.
>

I see.

> > I dare say punie suffers from a very bad name. People think it's a toy
> > compiler/interpreter.
>
> Never underestimate the power of being underestimated.
>

:-) Well, I still like "rindolf" or whatever better, and think we can think of
other better names.

> > Fair enough. Of course, you may wish to look at the beginning of:
> >
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0703.3/1296.html
> >
> > for some examples why being liberal on commit bits can be a good thing.
>
> Hmmmm... that's a thread that could have been started with more
> diplomacy. :)
>

Heh, maybe.

> I generally find that the people with the greatest dislike of a waiting
> period for commit access are the ones with the greatest need of a
> waiting period for commit access.

I see. I accept that.

> > Oh, I see. Does it mean I'm going to fork the punie code into rindolf in
> > a separate repository,
>
> If you want to. I would suggest instead first learning how the Punie
> code works, then adding a feature to the Punie code as a patch, or maybe
> even a few features. At that point you'll be in a better position to
> know if you really need a fork, or if it's better to just carry your
> gained knowledge and experience to a new task.

You're right, of course. I believe that was my original intention as well.

>
> Have you considered the fact that with the Parrot compiler tools you
> could implement your rindolf spec directly without first implementing
> Perl 5?

Hmmm - how would I implement an implementation for a Rindolf language from
scratch all at once? I'm a firm believer in bottom-up engineering, in
incremental and test-driven development and in avoiding over-engineering.
First, I'd like to have a full Perl 5 frontend working. Then, I can think of
extending it with more features.

But writing something so large of scope from scratch is probably not going to
work.

Allison Randal

unread,
Mar 31, 2007, 2:52:16 AM3/31/07
to Shlomi Fish, perl5-...@perl.org
Shlomi Fish wrote:
>
> Hmmm - how would I implement an implementation for a Rindolf language from
> scratch all at once? I'm a firm believer in bottom-up engineering, in
> incremental and test-driven development and in avoiding over-engineering.

Write a test for one language feature, then implement that feature. Then
write a test for another language feature, and implement that feature.
The same way you'd implement Perl 5 or Perl 1 on Parrot.

Allison

Shlomi Fish

unread,
Mar 31, 2007, 8:51:01 AM3/31/07
to Allison Randal, perl5-...@perl.org
On Saturday 31 March 2007, Allison Randal wrote:

Then I might as well as implement Perl 5 first and then and only then its
Rindolf (or whatever) superset. But first I want to get the Perl 5 part
working.

Richard Foley

unread,
Mar 31, 2007, 11:04:36 AM3/31/07
to perl5-...@perl.org, Allison Randal, Shlomi Fish
On Saturday 31 March 2007 06:35, Allison Randal wrote:
>
> > I dare say punie suffers from a very bad name. People think it's a toy
> > compiler/interpreter.
>
> Never underestimate the power of being underestimated.
>
It's possible to trip over false modesty, too.

> > Fair enough. Of course, you may wish to look at the beginning of:
> >
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0703.3/1296.html
> >
> > for some examples why being liberal on commit bits can be a good thing.
>
> Hmmmm... that's a thread that could have been started with more
> diplomacy. :)
>

Diplomacy? What's that then ?-)

--
Richard Foley
Ciao - shorter than aufwiedersehen

http://www.rfi.net/

ps. Please resend any bounced or unanswered emails.

Reply all
Reply to author
Forward
0 new messages