[OT] Re: Parrot and PGE will save the day (was Re: as if [Was: Selective reuse of storage in bless.] )
Rob Kinyon skribis 2006-01-20 23:12 (-0500):
$ perl -le '$h{1} = Perl; print values h'
Perl
$ perl -le 'push a, Perl; print @a'
Perl
Now, that's an unadvertised feature! I think I need to revisit some golfs ...
Not worth the effort, because length('[EMAIL PROTECTED]') == length('push a').
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: Parrot and PGE will save the day (was Re: as if [Was: Selective reuse of storage in bless.] )
On 1/21/06, Rob Kinyon [EMAIL PROTECTED] wrote: I'm making a few assumptions here: 1) Since PGE isn't part of Perl6 (because it's written in PIR), it can be used as the parser/lexer/etc. for any language, not just Perl6. Rules, like regexes, are essentially language neutral. So that's true. 2) Since PGE can be lexically-scoped, one can change the entire grammar within a given block, including how variables are referenced, subroutines are called, etc. The grammar only governs the surface syntax. It does not automagically control semantics (e.g. whether .arguments are available, tying, blessing, et cetera). Moreover, writing a Perl 5 parser in PGE alone is... Very difficult. It can be done (eg. PPI), but taking it and emit PIR is a nontrivial task that would not magically happen. 3) Since everything is, at the heart, just a PMC, so long as the appropriate PIR is emitted, it doesn't matter how the userside code is written so long as the right parser/lexer/whatever is used to translate it to PIR. Again, that'd be handwaving, as Perl5-PIR compiler is currently not championed by anybody. The slightly less ambitious Perl5-PMCs project (Ponie) is also in need of a champion at this moment, and it does not guarantee sane interoperation with other PIR targetting compilers in itself, though we are certainly working on it. So, if all three assumptions hold, then your monolithic Perl5 script can easily inline any Parrot-targeted language you want, simply by doing the following: 1) Use Ponie. 2) Within a block, import the appropriate PGE module(s) to redefine the grammar to P6 and do what you need to do. No translator needed. The amount of effort of writing all this is no less heavy than that of a Perl5-to-Perl6 translator. :-) Also it makes sense to have multiple migration paths (runtime-level, bytecode-rewriting-level, source recompilation level), because different people are interested in different subprojects. The P5-to-P6 translator also could work when targetting the JavaScript runtime, or the CLR runtime, or generating native code via LLVM or D; in those places Ponie does not help at all. Audrey
Re: Parrot and PGE will save the day (was Re: as if [Was: Selective reuse of storage in bless.] )
On Sat, Jan 21, 2006 at 04:35:00PM +0800, Audrey Tang (autrijus) wrote: : Moreover, writing a Perl 5 parser in PGE alone is... Very difficult. : It can be done (eg. PPI), but taking it and emit PIR is a nontrivial : task that would not magically happen. Actually, PPI is not a good example of completeness, since PPI punts on the meaning of anything below the expression level. LaIt doesn't know the relative precedence of operators, for instance, last I checked. But yes, the main point of writing the P5-to-P5 [sic] translator is so that nobody ever has to write a Perl 5 parser ever again. It just happens that I also need one of those for the P5-to-P6 translator. :-) Larry
Re: Parrot and PGE will save the day (was Re: as if [Was: Selective reuse of storage in bless.] )
The purpose of the P5-to-P6 translator is mostly to provide warm fuzzies. That's how it worked out for a2p, anyway. People knew they had the translator available, but mostly just translated their stuff piecemeal by hand. They primarily used the translator for educational purposes--feed a bit of awk code to it and see what it spits out for the equivalent Perl 1 code. But you should probably not think of P5-to-P6 as a mere translator. It's intended (eventually) to be a refactoring tool for turning N ways of doing things into the standard way, and that's something mere emulation can never give you. In particular, OO usage needs a lot of refactoring. Plus popular source filters such as Switch will need plugins to backtranslate to the equivalent Perl 6 idioms. And all this needs to be customizable by the user requesting the translation. That being said, it doesn't matter how good we make the translator, people will tend to rely on emulation forever. And that's okay too, as long as someone is willing to maintain the emulator, and as long as that someone isn't me. That's why I claimed the translation end of it for my own. :-) Even the translator will have to rely on a certain amount of emulation for constructs that don't map well into Perl 6 directly or don't have a decent refactoring yet. And no amount of automatic refactoring can reliably turn incorrect code into correct code. Larry
Parrot and PGE will save the day (was Re: as if [Was: Selective reuse of storage in bless.] )
On 1/20/06, Nicholas Clark [EMAIL PROTECTED] wrote:
On Fri, Jan 20, 2006 at 04:20:54PM -0500, Rob Kinyon wrote:
Pros: Larry doesn't have to do anything more on the WMoT.
Cons: The community, for some reason, really wants this
auto-translator, even though there wasn't one for P4-P5 and P5-P6 is
a greater leap than P4-P5 was.
But (as I understood it) the P4-P5 leap was not intended to be so great
that a translator would be needed. In fact, that confuses cause and effect.
Because the technology wasn't there to write a translator, it constrained the
size of the leap. The important part was that for Perl 5 to still be Perl,
it had to keep running the vast majority of Perl scripts.
In fact, Perl 5 still strives to maintain Perl 1 compatibility (and the
perl5-porters joke is that even thinking about breaking this is the fastest
way to summon the thought, er backwards compatibility police with a script
he's been running unchanged since 1987). Why else can you still:
$ perl -le '$h{1} = Perl; print values h'
Perl
$ perl -le 'push a, Perl; print @a'
Perl
Now, that's an unadvertised feature! I think I need to revisit some golfs ...
I believe that the translator is seen as needed (even by @Larry, I think)
to maintain the same level of continuity in the Perl 5-6 transition as
Perl 4-5 - your existing monolithic script runs on the newer Perl
interpreter, and you can edit (within that same file) as and when you need
to.
Otherwise you're in the situation where you can only inter-operate languages
the whole file level. Which means that it's the same actions to migrate from
Perl 5 to (say) Python as from Perl 5 to Perl 6. And somehow I think that
$Larry has some bias about which language he'd prefer everyone to find it
easiest to migrate to, even if he's too modest to admit it.
Please don't take offense at this, but I believe you're using 20th
century thinking. The two most important features in Perl6 aren't -in-
Perl6 - they're Parrot and the PGE. Both of them make a translator
unnecessary. More precisely, they make a file-in-P5 to file-in-P6
translator unnecessary because you can have block-level
interoperability.
I'm making a few assumptions here:
1) Since PGE isn't part of Perl6 (because it's written in PIR), it
can be used as the parser/lexer/etc. for any language, not just Perl6.
2) Since PGE can be lexically-scoped, one can change the entire
grammar within a given block, including how variables are referenced,
subroutines are called, etc.
3) Since everything is, at the heart, just a PMC, so long as the
appropriate PIR is emitted, it doesn't matter how the userside code is
written so long as the right parser/lexer/whatever is used to
translate it to PIR.
So, if all three assumptions hold, then your monolithic Perl5 script
can easily inline any Parrot-targeted language you want, simply by
doing the following:
1) Use Ponie.
2) Within a block, import the appropriate PGE module(s) to
redefine the grammar to P6 and do what you need to do.
No translator needed.
Rob
