Simon Cozens wrote:
On the other hand, maybe I'm being as shortsighted as Thomas J Watson [1] and that once the various operating systems do get their Unicode support together and we see the introduction of the 50,000 key keyboard,
Of course, scary 50K keyboards aren't really necessary. All we really need is a keybord with configurable keys. That is, each key has an LED, or OLED, or digital plastic surface, and an index key that allows you to select the Unicode block to be currently mapped onto the keyboard. I imagine there would also be some user-programmable hot-keys to shortcut to the blocks one uses regularly, and almost certainly the ability to create "virtual blocks", so one could easily set up an "ACSII plus angle quotes" block specifically for Perl 6 programming.
Or, for those on MacOS or X11, you could create your own keyboard mapping (e.g. http://wordherd.com/keyboards/ for MacOS), with angle quotes mapped onto, say, option-< and option->. Or just use the existing keyboard mappings for those two operators (e.g. option-\ and option-| respectively on MacOS). Or set your editor config file to insert the characters for you. For example, in .exrc: map <<<< « map >>>> » Remember, we're only talking about C<«> and C<»> as standard Perl 6 operators. Or, at worst, a few other Latin-1 codepoints as well. It's not as though we're defining dozens of Cyrillic, Bengali, or Hiragana symbols (though I must confess that 309D -- HIRAGANA ITERATION MARK -- sounds like a great candidate for an operator version of C<loop> ;-).
I dunno. I just think that right now, it's a crazy idea. And if we have
user-definable operators *anyway*, it's a doubly crazy idea.
Just make everything be user-definable multimethods.
My problem with that is that it's effectively the same solution Perl 5 provided for switch statements. That is: let them build their own. The reason Perl 6 has a single built-in switch mechanism is that in Perl 5 everybody *did* build their own switch statement. Differently. :-(
In fact, that's another reason for not using . for the bit ops: I'd like to be able to see $a .+ $b
as being equivalent to
$a.+($b)
That is, calling the + method on $a.
Great minds obviously think alike. That's what it *will* do. Except it's: $a + $b that's equivalent to the multimethod call: operator:+($a,$b)
This way you also get to choose which of the multimethods gets applied for free...
Err, no you don't. The whole point of multimethods is that *they* choose, based on the dynamic types of *all* their arguments. Damian
