Audrey Tang wrote:
As I'm writing this, I noticed that Allison has ruled that we go with
PIR/PGE and eventually C-based libpge instead
-- since a lexer refactoring that doesn't affect the IMCC API will
somehow throw important projects on Parrot into a
"dead stall", and thread safety for PIR compilation is not a 1.0 goal
anyway -- I'll abandon working on this, and
focus on helping getting a C-based libpge started instead. :-)
LOL :) Audrey, I love you dear, but you always have an interesting way
of interpreting what I say. :)
Yes, I'm not willing to start a 6+ month project to gut IMCC. The cost
is too great and the benefit isn't great enough.
If you have a way to make IMCC reentrant that involves upgrading to a
more recent version of flex and passing one additional parameter, go for
it! Send us a patch and if it passes all the tests, we'll apply it.
It's still true that:
- We need an OST-to-bytecode compiler for the compiler tools. (I suspect
it will solve some of your problems too, as you'll no longer need to
embed Parrot to generate Parrot bytecode. You'll be able to generate it
from a C library instead and just run the bytecode on Parrot.)
- A PIR parser written in PGE is a good idea (and will be dead simple
anyway, as PIR is a simple language).
- A version of PGE written in C is a good idea, because it will spread
Perl 6 regexes/grammars far and wide. (It will be difficult, because of
all the Parrot features that will have to be reimplemented in a
standalone PGE. But, it is possible.)
- If those things combine to produce a cleaner, more maintainable
alternative to IMCC, it's good for Parrot. If not, then the separate
components are still good for Parrot.
There's more than one way to do it,
Sometimes you should do both,
Allison
