But we also have the ambiguity with <<'' and friends, so maybe the real problem is trying to make the << and >> workarounds look too much like « and ». Maybe they should be :<< and :>> or some such. Maybe we should be thinking about a more general trigraph (shudder) policy.
Nooooooooooooooooooooooooooooooooooooooooooooooooooooooooo!!!!!!!!!
;-)
Or some other kind of "entity" policy. Though I don't think people would be terribly pleased when they see things like:
@a »+<<« @b
Agreed!
Particularly since the "r" one goes on the left, and the "l" on goes on the right. Still, it's potentially a lot less ambiguous, and puts people into the "preprocessing" frame of mind, and would certainly motivate people to move toward editors and terminals that can display:
@a »+<<« @b
Yes, it would be an excellent motivation in that direction. But, then, so would *not* providing any ASCII-based alternative in the first place.
And we wouldn't have to define yet another arbitrary list of mappings.
Here, here! I certainly believe that any entity notation must use the "standard" (i.e. HTML and/or Unicode) names for entities.
On the other hand, we'd probably have to require a () on the &foo() notation to distinguish it from an &foo; entity.
Which would seem to suggest that the Huffman coding is backwards. I expect to use constructs like:
my Code $clocks_ref = ×
far more often than I'd use something like:
my Vector $outer = $vec1 × $vec2;
especially since I'm already using an OS that makes it trivial to code the latter "properly":
my Vector $outer = $vec1 × $vec2;
Frankly, I'd *much* rather see:
@sum = @a E<raquo>+<<E<laquo> @b;
my Vector $outer = $vec1 E<times> $vec2;
which at least has the benefit of being consistent with POD notation.
(Note that, if we *do* decide to support some kind of ASCII-based entity notation, we really must make sure it's the same in both Perl code and POD mark-up.)
Damian
