Since Perl6 will treat any code as "old code" unless it starts with one of the new keywords...

And, yes, we're going to need some way to distinguish Perl 6 code from Perl 5 code. Because there are a few simple cases that mean completely different things in Perl 5 and Perl 6. For example:

    print $hash{bang};
[download]

In Perl 5 that means: print the value of the entry of %hash whose key is "bang".

In Perl 6 that means: print the value of the entry of the hash referred to by $hash whose key is "bang".

How could we distinguish Perl 5 and Perl 6 code? I'd suggest we add a <code6> flag and have the monastery render code marked as Perl 6 in a different font. For example, the submission:

    We're going to need some way to distinguish:
    
    <code>
        print $hash{bang};  # entry 'bang' of hash %hash
    </code>
    
    from:
    
    <code6>
        print $hash{bang};  # entry 'bang' of hash %{$hash}
    </code6>

We're going to need some way to distinguish:

    print $hash{bang};  # entry 'bang' of hash %hash

from:

    print $hash{bang};  # entry 'bang' of hash %{$hash}

Note: I've used a red-shift/blue-shift visual pun here, but in reality we'd need to use distinct font faces -- perhaps serif for Perl 5 and sans-serif for Perl 6 -- so as not to disadvantage those with impaired colour vision.

Using a separate mark-up tag would also support those monks who (through necessity or by choice) use a non-visual browser.

How could we distinguish Perl 5 and Perl 6 code? I'd suggest we add a <code6> flag and have the monastery render code marked as Perl 6 in a different font.

Personally I find such conventions easy to quickly forget with disuse because the association of font and language is arbitrary. I think this will not be of much help to occasional users or first-timers here. I see a lot of edits to add code tags and such now.

I like this idea, the idea just doesn't address the problem as I was envisioning it.

Something like halley's suggestion puts the issue explicitly in front of every seeker. Perhaps to the left of the Title entry widget something like a required selection widget:

This post relates to: Perl5 Perl6 Both N/A Don't Know

Whether the monastery would want to make someone who selects Dunno jump through more hoops before seeking wisdom is a tough question for me. I find such stealth dialogs unfriendly.

Personally I find such conventions easy to quickly forget with disuse because the association of font and language is arbitrary.

In general, of course, you're right. But in this particular case we're talking about two successive versions of the same language. So we have a clear temporal sequence. So I think we can have a very simple and self-evident mnemonic: use an older-looking font for the older language.

Hmmm. This is a little OT, but how would you do the equivalent of print $hash{bang}; in Perl 6? print %hash{bang};?

Maybe I should start reading the Apocolypses or something...

how would you do the equivalent of print $hash{bang}; in Perl 6? print %hash{bang};?

Exactly. In Perl 6 the sigils for arrays (@) and hashes (%) are an intrinsic part of the variable name and consequently don't change when the variable is accessed.

Maybe I should start reading the Apocolypses or something...

Good idea. They're most easily accessed at: http://dev.perl.org/perl6/apocalypse/.

The Exegeses and Synopses are also quite useful.

how would you do the equivalent of print $hash{bang}; in Perl 6? print %hash{bang};?

That's right. I think sigils on hashes and arrays (when accessing elements or slices) are one of the most confusing things for beginners, and this is an effort to correct that. I think $hash{bang} can be optionally $hash.{bang} (remember "->" is changing to "."), but you can leave out the '.' since its unambiguous either way.

I had to visit this page using IE to see what you meant. My Mozilla client displays everything sans formatting. However this happens, it needs to be visible within the text and not merely an applied style.

Which is exactly why I suggested distinguishing tags.

However, perhaps the correct answer is for senior monks to start using a standard convention when the language in question is not obvious from context:

    # P5
    print $foo{bar}.baz();   # bar entry of %foo, 
                             # then concat result of baz()
[download]

vs:

    # P6
    print $foo{bar}.baz();   # call baz() method on
                             # bar entry of %$foo
[download]