Re: State of Perl6 Backends
Audrey Tang
在 2006/6/22 下午 8:18 時，Swaroop C H 寫到：
> Hi Audrey,
>
> I'm hell confused on the state of the numerous Perl6 backends that
> we have :-). As I understand it, there is no "main" backend right?
> First there is the Pugs part written in Haskell that compiles to
> PIR which Parrot can run, and similarly it compiles to JavaScript /
> CIL / etc ? Then, we have the misc/pX/Pugs-Compiler-Perl6 which is
> a p6-to-p5 translator. Is my understanding correct?
>
That is completely correct, although we don't compile to CIL at the
moment.
> Going forward, what will be the "main" backend? I mean what will be
> the one that will be used in production? I am assuming we have all
> this because of the bootstrapping problem?
The "main" backend as I see it, in the near future, is definitely the
Perl 5 runtime for production use, because a new runtime (be it GHC
or Parrot or SpiderMonkey) always faces a far higher barrier of
entry. Codegen to that runtime is probably going to be written in
Perl 5 in Pugs::Compiler::Perl6 space, although it may also happen at
Perl 6 space, Parrot space, or Haskell space. (The author-side tools
has higher flexibility; the client-side runtime must only assume pure
Perl5 and maybe selected well-known XS modules.)
But in the long run, it'll just be different runtimes for different
environment. Python has maybe 10 implementations, half of them quite
complete; Scheme has more than 20; it's really good for Perl 6 to be
retargettable across different runtimes as well.
>
> Sorry for the numerous questions, but I'm so curious, and I didn't
> know which list to send this to (internals vs compiler vs users ?? )
>
-compilers is probably it; Cc'ed them. :-)
Thanks,
Audrey
Swaroop C H
> The "main" backend as I see it, in the near future, is definitely the
Codegen to that runtime is probably going to be written in
> Perl 5 in Pugs::Compiler::Perl6 space, although it may also happen at
> Perl 6 space, Parrot space, or Haskell space. (The author-side tools
> has higher flexibility; the client-side runtime must only assume pure
> Perl5 and maybe selected well-known XS modules.)
So, as of now, you envision svn:/pugs/misc/pX/Common/Pugs-Compiler-Perl6 to
be the "main" engine for Perl 6 ?
Will this be written only in pure Perl 5 ?
And parts of it will be rewritten in Perl 6, and thereby eventually we'll
have a Perl 6 engine itself written in Perl 6 ?
If this is the case, is the purpose of the other backend engines simply
-Ofun or more than that? :-)
Where does Parrot fit in all of this?
But in the long run, it'll just be different runtimes for different
> environment. Python has maybe 10 implementations, half of them quite
> complete; Scheme has more than 20; it's really good for Perl 6 to be
> retargettable across different runtimes as well.
>
Makes sense. It's good to have different engines suitable for different
purposes ...
Thanks for taking the time to reply!
Swaroop
Chromatic
> So, as of now, you envision svn:/pugs/misc/pX/Common/Pugs-Compiler-Perl6 to
> be the "main" engine for Perl 6 ?
I believe Audrey's point was that it is the most complete implementation right
now.
> If this is the case, is the purpose of the other backend engines simply
> -Ofun or more than that? :-)
They're all at various stages of incompleteness. Some people believe that
specifying a common minimal subset of Perl 6 (or an intermediate language
which can represent Perl 6) will allow nearly simultaneous bootstrapping on
multiple backends.
> Where does Parrot fit in all of this?
I am speaking for myself, not Audrey (or anyone else) here. I believe that it
will be the most complete and most performant backend in the near and medium
future.
> Makes sense. It's good to have different engines suitable for different
> purposes ...
Yes and no. Having multiple incomplete and incompatible implementations is
fairly uninteresting. (Multiple complete and incompatible implementations
isn't much better; try writing a complex CL program on one platform and
deploying it to another sometime.)
-- c
Audrey Tang
在 2006/6/23 上午 9:50 時，chromatic 寫到：
> On Friday 23 June 2006 00:04, Swaroop C H wrote:
>
>> So, as of now, you envision svn:/pugs/misc/pX/Common/Pugs-Compiler-
>> Perl6 to
>> be the "main" engine for Perl 6 ?
>
> I believe Audrey's point was that it is the most complete
> implementation right
> now.
No, that is not my point at all. It's not even true. :-) The Pugs/
Haskell runtime is currently the most complete, and I wouldn't
suggest deploying that in production for most places currently using
Perl 5 at this point, because for that a runtime needs to guarantee
compatibility with Perl 5 XS modules and interoperability with the
Perl 5 calling convention (e.g. what Ponie set out to do), which the
Haskell runtime only does partially with significant GC/memory-leak
issues.
The Perl 5 runtime/emitter of P::C::P is currently at a comparable
state as Parrot/Perl6 -- neither of them handle the calling
convention, neither runs the toned-down Perl4-level Test.pm, and
their object space support is "basically" working at the internals
level (ParrotObject and Moose), but still entirely hidden from the
userland.
Of course, I'd like to get Test.pm working for both, and try to agree
on the calling convention and object space semantics, at the Chicago
hackathon.
>> Makes sense. It's good to have different engines suitable for
>> different
>> purposes ...
>
> Yes and no. Having multiple incomplete and incompatible
> implementations is
> fairly uninteresting. (Multiple complete and incompatible
> implementations
> isn't much better; try writing a complex CL program on one platform
> and
> deploying it to another sometime.)
Indeed. So instead of having the implementions define the language,
this time around the specs, and tests, and API documentations, need
to be adhered closely by implementors, which is why we're all talking
together in #perl6 in the past few months or so. :-)
Multiple implementations that are compatible to the spec, like the
R5RS Scheme, are really a very good thing.
Thanks,
Audrey
Chromatic
> Multiple implementations that are compatible to the spec, like the
> R5RS Scheme, are really a very good thing.
Only insofar as the spec is complete enough that an implementation that adds
nothing beyond that is useful and that there exists somewhere a set of
core-ish libraries that work on conformant implementations.
Scheme's not entirely perfect there.
-- c
Uri Guttman
AT> Indeed. So instead of having the implementions define the language,
AT> this time around the specs, and tests, and API documentations, need
AT> to be adhered closely by implementors, which is why we're all talking
AT> together in #perl6 in the past few months or so. :-)
that was a good leadin for me to remind anyone at the chicago hackathon
that we are going to also do a docathon. i actually printed up (double
sided to save trees) the full set of synopses from perl.org. (not the
most up to date but good enough). i will be marking it up as i read
it. i would like to get some of you to do more proofreading at the
docathon and we can integrates our patches, rewrites, questions while a
large corps of p6 hackers will be around. take a break from hacking p6
and hack the p6 docs!
sign up and post your ideas at:
http://yapcchicago.org/wiki/index.cgi?SynopsisEdit
(i should have called it DocAthon. maybe i will rename it)
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org