Larry Wall wrote:
I should point out that we're still contemplating breaking .foo() so it
no longer means $  I wish there were more keys on my keyboard...

I know it's a bit counter-cultural, but at the moment I'm wondering
if we can make this work instead:

    given open 'mailto:[EMAIL PROTECTED]' {
        _close or fail;

We do, after all, have better ways of declaring private methods and
functions now. so maybe we don't need to reserve _ for that anymore.
And it would save two characters over $  But recovering C

I kind of like that, but see below.

programmers will scream, and probably prefer, even if it only
saves one character.  Maybe it's time to raid Latin-1 for the next
closest thing to a dot, "middle dot":

    given open 'mailto:[EMAIL PROTECTED]' {
        ·close or fail;

But I'm sure some will argue that's too subtle. (Hi, @Larry<Damian>.)

I agree, too subtle.

Well, hey, as long as we're looking at Latin-1, we could use superscripts
to indicate nested topic defaults.

    given open 'mailto:[EMAIL PROTECTED]' {
        close¹ or fail;

Then foo² would be $, foo³ would be $

Or we go back to .foo always meaning $ and use ¹.foo to call the
first invocant, ².foo to call the second, ³.foo to call the third.
Interestingly,,, etc. would work as ASCII workarounds
if we didn't autobox literal numbers.

Given I like, we can get around the autobox problem by using,, etc. Even though those are legal(?) variable names I've never seen them used in code anywhere.

But I rather like ` for user-defined literals.  I suppose bare ^
is also available:

    given open 'mailto:[EMAIL PROTECTED]' {
        ^close or fail;

This kind of works also. And it would allow ^, ^, etc. or even ^^.foo(), ^^^.foo(), etc (nah!).

That almost makes sense, given that $^a is like $_.  It also points vaguely
upward toward some antecedent.  I could maybe get used to that, if I
tried real hard for a long time.  Almost makes we wish we could rename
$_ to $^ though.  Hmm...

Too late, maybe.


Reply via email to