On Fri, Apr 22, 2005 at 09:09:21PM +0200, Juerd wrote:
: Matt skribis 2005-04-22 14:44 (-0400):
: > We're talking about the *built-in* functions here, right?
:
: I don't know.
:
: > Anyway, is there any other URI scheme besides for mailto: that doesn't use
: > <://>?
:
: I don't know, but if you want to find this out,
: http://www.iana.org/assignments/uri-schemes is probably a good starting
: point.
:
: > mailto isn't something you can "open" really, for read at least.
:
: No, but writing to it ought to simplify things :)
:
: given open 'mailto:[EMAIL PROTECTED]' {
: .say(q0:to<.>
: Subject: Useful mailto open
: User-Agent: Perl 6
: In-Reply-To: <[EMAIL PROTECTED]>
:
: Hello, world!
: .
: );
: .close or fail;
: }
I should point out that we're still contemplating breaking .foo() so it
no longer means $_.foo(). 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]' {
_say(...);
_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 $_.foo(). But recovering C
programmers will scream, and probably prefer _.foo(), 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]' {
�say(...);
�close or fail;
}
But I'm sure some will argue that's too subtle. (Hi, @Larry<Damian>.)
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]' {
say�(...);
close� or fail;
}
Then foo� would be $OUTER::_.foo(), foo� would be $OUTER::OUTER::_.foo().
Or we go back to .foo always meaning $_.foo and use �.foo to call the
first invocant, �.foo to call the second, �.foo to call the third.
Interestingly, 1.foo, 2.foo, 3.foo etc. would work as ASCII workarounds
if we didn't autobox literal numbers. Though that would put a crimp
in the Rubyish
3.times:{ say "It's true!" }
Okay, that's kinda nuts. How 'bout we change ! to � and then we can
say:
given open 'mailto:[EMAIL PROTECTED]' {
!say(...);
!close or fail;
}
Sigh. We could also take ` away from user-defined literals and say
given open 'mailto:[EMAIL PROTECTED]' {
`say(...);
`close or fail;
}
But I rather like ` for user-defined literals. I suppose bare ^
is also available:
given open 'mailto:[EMAIL PROTECTED]' {
^say(...);
^close or fail;
}
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...
: > If it's for built-in, then only the most common protocols would be defined
: > I imagine.
:
: No, if it's built in, we should stick to the spec and interpret every
: ^\w+: (roughly - see RFCs for syntax specifics) as a scheme.
Yes, especially the c: scheme. :-)
Larry
