PDS Aftermath. Which way NQP?

[Richard Hainsworth]

Seems the guidance about NQP for the toolchain that Bruce Gray asked for 
has sparked responses to a wider debate.

It is clear that the toolchain needed for parrot needs to be written in 
an HLL for the very reasons that HLLs are better than low level 
languages in the first place.

So one question in this thread is which HLL should parrot adopt for its 
tool chain?

Some requirements for this toolchain HLL:
- it should provide access to all aspects of Parrot
- it should "belong" to the Parrot community so that when changes are 
made to Parrot, changes can be made in the HLL to keep consistency with 
the point above
- it should only have sufficient constructs to achieve the tasks of 
creating the Parrot tool chain.
- it could be a model for other HLL developers to see how to do things.

It does not really matter which HLL is used, so it could be like an 
established one, or be completely new.

Seems to me that designing a new HLL would divert the resources of the 
Parrot community, so that would be a bad choice.

The toolchain HLL is therefore likely to mimic some other more 
established language. Whichever choice is made will rub a fan of another 
language the wrong way, so its unlikely that a choice can be made that 
everyone will like.

NQP was used to create the first tool chain. It has a codebase that can 
be modified. It already works. That it is a subset of Perl6 is a part of 
its history and the history of Parrot.

Maybe NQP should be renamed to something more Parrot-like, eg. para-tc?

A second question is the relationship between Rakudo and Parrot. They 
are different, though their histories are intimately linked. At some 
point the needs of the two language communities will diverge 
significantly. This is probably one such moment.

Rakudo needs a target that can have multiple back ends, Parrot needs an 
HLL for its tool kit. Up until now, NQP has served both needs. 
Maintaining NQP so that it continues both needs is no longer possible, 
which is effectively what the Rakudo developers have stated by 
publishing a new specification for NQP.

It seems to me that NQP should fork into two similar but different 
languages, one for Parrot's tool chain, and one for Rakudo's target. If 
they were called different things, it would keep the two contexts clear.

Richard <finanalyst>