Working on punie + rindolf (the implementation) Reloaded

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.shlomif
ish.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      shlomifiglu.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

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.shlomif
ish.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

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.shlomif
ish.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.



Regards,

	Shlomi Fish

------------------------------------------------------------
---------
Shlomi Fish      shlomifiglu.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

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

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. 

Regards,

	Shlomi Fish

------------------------------------------------------------
---------
Shlomi Fish      shlomifiglu.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

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

On Saturday 31 March 2007, Allison Randal wrote:
> 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.
>

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.

Regards,

	Shlomi Fish

------------------------------------------------------------
---------
Shlomi Fish      shlomifiglu.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

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.