Note: this ended up looking like a call for a Policy, when really it is
just a request for guidance and timely discussion. Also, much of it was
written amidst the PDS heated discussion of NQP's suitability to
remain in
the Parrot repo. Later discussion in #parrot looks to have arrived at an
amicable consensus, but I am not *sure* that the removal from the repo
is
off the table. Even if so, the questions are worth asking. (and I
already
typed them).
Given that:
1. Parrot has been moving away from Perl 5 within Parrot's own code,
build harness, tests, and test harness.
2. Bootstrapping schemes now could allow many parts of Parrot (even
pmc2c & ops2c) to be written in *any* Parrot-based language,
including
NQP or Perl 6.
Question: Which languages should Parrot allow in its core to be
written in?
(or, what is it OK to write pmc2c|ops2c|pbc_to_exe|TestHarness|etc in?)
((I am probably wrong on at least one of my provided answers;
"Patches" welcome, and nit-picking encouraged.))
Perl 5?
Obviously not! If it *were* acceptable, we would not have moved all
that Perl 5 code into PIR, now would we?
Perl 6?
No, for political reasons; Having chunks of Parrot written in Perl 6
will be disagreeable for Perl 6's "competitors". Isn't this why PaFo
is separate from the Perl Foundation?
C?
Acceptable, but only where PASM/PIR are problematic. For example,
IMCC
is being replaced, having been a long-term thorn due to its C-ness.
PASM?
Definitely acceptable.
(but rarely optimal or even advisable for anything not tiny)
PIR?
Definitely acceptable, and usually preferred.
(but sometimes sub-optimal; the few large PIR programs make us wish
for something higher level)
There would be some benefit, though, if nothing was above PASM/PIR
level.
No real bootstrapping concerns!
(Whoops, not true with IMCC's replacement)
NQP?
(This is *my* big issue, because I need to know whether to move
forward with pbc_to_exe in NQP.)
On one hand, ops2c was converted from Perl 5 directly to NQP (rather
than to PIR), and is currently NQP (via bootstrapping) in the master
branch. I expect pmc2c.pl to go the same route in the future.
I have converted pbc_to_exe from PIR to NQP (but not in a public
branch yet), with the intention of looking for more large PIR
programs
to convert to NQP in the future. I think that pbc_to_exe, at least,
has suffered from people not wanting to dive into high line-counts
of PIR.
On the other hand, anything we are writing in NQP *could* be written
in PIR, at some increased maintenance cost.
On the gripping hand, the IMCC replacement (PIRATE) is written in
NQP,
so "no NQP in Parrot" == "big step backwards".
[Other, *future* possibilities]
QJS? (PIR++)?
Since IMCC is the thing that has been holding back the evolution of
PIR, and IMCC will soon be replaced by something easier to modify,
we
could see improvements to PIR that would alleviate some of the need
for a NQP-level language. However, not all past limits to PIR's
evolution have been IMCC's fault. PIR has been intended as fairly
low-level in the past, with just enough sugar over PASM to keep
everyone from choking. To enhance PIR to anywhere close to NQP's
level
would be a major change in philosophy.
Not-Quite-NQP?
Something similar to NQP could be created, to forever be oriented to
Parrot's own needs. Particle mentioned forking the current NQP.
J_Random_HLL?
Imagine a future where Perl, Python, Ruby, PHP, JavaScript, and
every
other mainstream HLL all have stable implementations on Parrot.
Someone contributes a brilliant new optimizer for our much-envied
JIT
subsystem. The optimizer is written in, let's say Javascript.
Would we
adopt it as-is? Hand-convert it to NQP? Repeat the scenario with
your
most desired missing code, written in your own least favorite
languages. See any need for a policy, or even a rule-of-thumb?
My take on the original discussion is less that NQP is walking away
from Parrot,
and more that NQP is walking in a direction that it dearly hopes Parrot
will also soon follow.
My two cents on that issue:
If we want Parrot to be the best platform for HLLs, doesn't it make
sense
to arm ourselves with the best HLL implementation tools? Isn't it wise
to
package (or even tightly couple) Parrot with NQP, PCT and any other
brilliant-HLL-writing-thing-that-comes-out-of-pmichaud's-head?
Thanks to all who spoke so well, with so little vitriol.
Special thanks to kid51++ for organizing this highly productive
Developer's Summit.
--
Bruce Gray (Util of PerlMonks)
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
