perl6 list and neat (?) golf trick

Rob Kinyon <[email protected]> wrote
>> $ 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 sure I can ... certainly can't think of any useful way to use this but 
you golfers might.

a

Andy Bach, Sys. Mangler
Internet: [email protected] 
VOICE: (608) 261-5738  FAX 264-5932

I have great faith in fools -- self confidence my friends call it.
        -- Edgar Allan Poe

----- Forwarded by Andy Bach/WIWB/07/USCOURTS on 01/23/2006 10:57 AM -----


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