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