Front page | perl.perl6.language |
Postings from January 2004
Larry mused:
> 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
Thread Previous
|
Thread Next