faq
Marius Nita
I have a question about the Parrot FAQ. I hope it's not too off-topic for this
list. The FAQ mentions that "it would be nice to write the Perl to Bytecode
compiler in Perl" and that there is no bootstrap problem.
Does this mean that the perl6 compiler is written in perl5 and it will be
rewritten in perl6 when a large enough subset of perl6 is implemented? I
figure Perl5 will be obsolete at some point in the future...
I noticed that the current incomplete perl6 implementation is written in perl5
using Parse::RecDescent, but I figured it's just a test implementation until
the "real" compiler is written in C...
Thanks
marius
Markus Laire
> Hello,
>
> I have a question about the Parrot FAQ. I hope it's not too
> off-topic for this list. The FAQ mentions that "it would be nice to
> write the Perl to Bytecode compiler in Perl" and that there is no
> bootstrap problem.
>
> Does this mean that the perl6 compiler is written in perl5 and it
> will be rewritten in perl6 when a large enough subset of perl6 is
> implemented? I figure Perl5 will be obsolete at some point in the
> future...
perl6, or parrot, or something else which runs on parrot.
With parrot you have a lot of possibilities on which languages to use
(once it's complete).
> I noticed that the current incomplete perl6 implementation is written
> in perl5 using Parse::RecDescent, but I figured it's just a test
> implementation until the "real" compiler is written in C...
perl5 won't be used anywhere when all is ready.
There will be small 'miniparrot' (currently in development), which
can be build with just C compiler [was anything else required?].
Miniparrot can then be used to build everything else, including full
parrot, perl6, other parrot-supported languaged, etc..
This 2nd step might be e.g. Bytecode-compiled perl6-program which is
simple enough to work with miniparrot.
(Here might be some mistakes, but this is as I understand this, based
on active lurking here)
--
Markus Laire 'malaire' <markus...@nic.fi>
Gopal V
> Miniparrot can then be used to build everything else, including full
> parrot, perl6, other parrot-supported languaged, etc..
>
> This 2nd step might be e.g. Bytecode-compiled perl6-program which is
> simple enough to work with miniparrot.
Please for heaven's sake don't write a perl6 compiler in perl6 ... It's
*very* frustrating if I have to download version 1 to compile 1.1 and
so on... (imagine compiling CVS head with a chain of older stuff) ...
And even that is suspect when the fingerprinting and other stuff changes
the binary packfile format ... (stuff like additional blobs or blocs have
been discussed lately).... I have seen instances where a fix to support
feature "x" will need feature "x" to compile .... Dependency hellhole..
This is especially true as parrot doesn't have a fully functional reference
implementation (like gcc using cc) to start a bootstrap .....
But yeah, I don't have any solutions either ...
Gopal
--
The difference between insanity and genius is measured by success
Nicholas Clark
> Gopal V:
> # If memory serves me right, Markus Laire wrote:
> # > Miniparrot can then be used to build everything else, including full
> # > parrot, perl6, other parrot-supported languaged, etc..
> # >
> # > This 2nd step might be e.g. Bytecode-compiled perl6-program which is
> # > simple enough to work with miniparrot.
> #
> # Please for heaven's sake don't write a perl6 compiler in
> # perl6 ... It's
> # *very* frustrating if I have to download version 1 to compile
> # 1.1 and so on... (imagine compiling CVS head with a chain of
>
> We have to--otherwise we can't have the self-modifying parser Larry
> desperately wants. But don't worry--we'll ship it already bytecompiled.
This is actually very similar to perl5, which strictly you can't actually
build from scratch without an existing copy of perl5.
However, all the header files generated by perl scripts (the target
make regen_headers) are shipped with the source kit. Once you've built a
perl5 from the distribution source you can actually run (by hand) them
without installing that perl, if you really want to.
I believe that this is directly comparable with shipping the perl6 parser
precompiled. It also means that we must be careful to prevent the compiled
perl6 parser becoming trojaned (as cc and login reportedly were on early unix
systems). Yes, I've only thought of this because of the recent tcpdump
trojan. But I think it's something we need to bear in mind.
Nicholas Clark
Brent Dax
# If memory serves me right, Markus Laire wrote:
# > Miniparrot can then be used to build everything else, including full
# > parrot, perl6, other parrot-supported languaged, etc..
# >
# > This 2nd step might be e.g. Bytecode-compiled perl6-program which is
# > simple enough to work with miniparrot.
#
# Please for heaven's sake don't write a perl6 compiler in
# perl6 ... It's
# 1.1 and so on... (imagine compiling CVS head with a chain of
We have to--otherwise we can't have the self-modifying parser Larry
desperately wants. But don't worry--we'll ship it already bytecompiled.
--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Marius Nita
> On 12 Nov 2002 at 16:40, Marius Nita wrote:
>
> > Hello,
> >
> > I have a question about the Parrot FAQ. I hope it's not too
> > off-topic for this list. The FAQ mentions that "it would be nice to
> > write the Perl to Bytecode compiler in Perl" and that there is no
> > bootstrap problem.
> >
> > Does this mean that the perl6 compiler is written in perl5 and it
> > will be rewritten in perl6 when a large enough subset of perl6 is
> > implemented? I figure Perl5 will be obsolete at some point in the
> > future...
>
> perl6, or parrot, or something else which runs on parrot.
> With parrot you have a lot of possibilities on which languages to use
> (once it's complete).
Thanks, this makes sense. There would still be 'a bootstrapping problem' since
the compiler would have to be rewritten in perl6. As I understand things,
Parrot is a bytecode compiler/interpreter, but a 'language compiler' has to be
written in some other language which already compiles to parrot assembly. (or
has a compiler in general -- like C) So if the perl6 compiler is
written in Cola/Jako/C/etc, it would have to be rewritten in perl6 once perl6
can be compiled with this (Cola/Jako/C/etc) compiler. Or a small subset of
perl6 can be implemented in perl5, and then it can be incremetally
implemented, at each stage using only the current available subset of perl6.
(which is classic bootstrapping)
I don't know how big of an issues this rewriting part is. I was just wondering
why the FAQ saw it as a non-issue, which led me to wonder whether rewriting is
necessary to begin with. I think it is.
Thanks,
marius
Dan Sugalski
>If memory serves me right, Markus Laire wrote:
>> Miniparrot can then be used to build everything else, including full
>> parrot, perl6, other parrot-supported languaged, etc..
>>
>> This 2nd step might be e.g. Bytecode-compiled perl6-program which is
>> simple enough to work with miniparrot.
>
>Please for heaven's sake don't write a perl6 compiler in perl6 ... It's
>*very* frustrating if I have to download version 1 to compile 1.1 and
>so on...
Oh, absolutely not. That's way too much of a headache, and too much
of a dependency.
The goal is for Parrot to require a C compiler and a platform shell
or Make tool (either one) and that's it. We will ship with bytecode
files that have the bits needed for the build precompiled, so if the
perl compiler's partially written in perl, we'll ship a perl6.pbc in
the distribution.
Yes, this will mean that people doing development on parrot will need
a working parrot setup, but as that should be easy enough to get
(given that it'll be available as a standalone distribution) it
shouldn't be a problem except on new and unusual platforms. Hopefully
not there, even, if proper tweaks to the core C code can be made.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Nicholas Clark
> The goal is for Parrot to require a C compiler and a platform shell
> or Make tool (either one) and that's it. We will ship with bytecode
> files that have the bits needed for the build precompiled, so if the
> perl compiler's partially written in perl, we'll ship a perl6.pbc in
> the distribution.
I believe that it can be done with just a C compiler. (no make tool or shell
needed). If we use an equipped machine to unroll the makefile into the correct
steps (in the correct order), and turn that into C code that runs each in
turn, then we can bootstrap enough to run bytecode. (and a bytecode make tool)
Please archive this message and hold it against me when the time comes, and
you're looking for someone to prove it by making it work.
Nicholas Clark
--
vapourware better than perl? http://www.perl.org/advocacy/spoofathon/
Josh Wilmes
> On Wed, Nov 13, 2002 at 03:06:03PM -0500, Dan Sugalski wrote:
>
> > The goal is for Parrot to require a C compiler and a platform shell
> > or Make tool (either one) and that's it. We will ship with bytecode
> > files that have the bits needed for the build precompiled, so if the
> > perl compiler's partially written in perl, we'll ship a perl6.pbc in
> > the distribution.
>
> I believe that it can be done with just a C compiler. (no make tool or shell
> needed). If we use an equipped machine to unroll the makefile into the correc
t
> steps (in the correct order), and turn that into C code that runs each in
> turn, then we can bootstrap enough to run bytecode. (and a bytecode make tool
We've actually already reached that point.
We currently generate a shell script with the build commands in it. We
could generate a .c file just as easily.
However, it's still necessary to tell it how to compile something somehow.
I think we can figure out the details when the time comes though- the
current shell script (which assume gcc/unix) is enough for now. We can
add other .bat/.com files for other platforms, just to get things
bootstrapped.
Once we get to the point that miniparrot is actually part of the parrot
build process, then we can revisit exactly how to build it.
My inclination is to provide a configure script for platforms where that
works, as well as native shell/bat/whatever is guaranteed to be available
on that platform (including .or .c, if appropriate) for
more unusual platform.
--Josh
Gopal V
> I believe that it can be done with just a C compiler. (no make tool or shell
> needed). If we use an equipped machine to unroll the makefile into the correct
> steps (in the correct order), and turn that into C code that runs each in
Hey that's unecessary ... what I was concerned about was a first step
bootstrap for compiling the perl6 compiler ....
I'm perfectly satisfied with the way parrot & miniparrot compiles work ..
On a really bad setup .. I can always dump the Makefiles somewhere and
use them..
If the Parrot team can provide a current and working perl6c.pbc for the
compiler written in perl6 , it's cool with me ... But I've seen that idea
fail quite a few times when the published binary falls out of sync with
the runtime ... Well that's just another point of failure ... That's all.
Also perl6c.pbc shouldn't really worry about trojaned stuff in it as you're
not using an external bootstrapper (unlike gcc using cc)....
Hope that makes it clear,
Nicholas Clark
> Also perl6c.pbc shouldn't really worry about trojaned stuff in it as you're
> not using an external bootstrapper (unlike gcc using cc)....
I don't think you're totally correct. You are still relying on an external
bootstrapper, although it's from a source you (think you) trust - the parrot
distribution.
If someone cracks the parrot distribution's server, and installs a trojaned
perl6c.pbc that contains extra routines to recognise when it is compiling
perl6c.pl, then the running perl6 compiler could interest its extra routines
into the bytecode of the perl6 compiler. And again next generation. And again
next ...
In the same way that the self-replication code for cc worked.
Nicholas Clark
Dan Sugalski
>If the Parrot team can provide a current and working perl6c.pbc for the
>compiler written in perl6 , it's cool with me ... But I've seen that idea
>fail quite a few times when the published binary falls out of sync with
>the runtime ... Well that's just another point of failure ... That's all.
The binary will be packaged up with each release, much like other
generated files are packaged up. (yacc generated files, for example)
If whoever did the release didn't manage to get it right, well, they
need to try again. :)
Simon Cozens
> We have to--otherwise we can't have the self-modifying parser Larry
> desperately wants.
That's funny. I wondered precisely why I'd been working on self-modifying
parsers in C.
--
10. The Earth quakes and the heavens rattle; the beasts of nature flock
together and the nations of men flock apart; volcanoes usher up heat
while elsewhere water becomes ice and melts; and then on other days it
just rains. - Prin. Dis.