On Saturday 06 October 2001 04:58 am, Erik Lechak wrote:
> a) I just plain don't like to use the "_" key. Hitting the "shift" key
> and the "-" key just does not feel right. I call this the
> Huffman-Carpel-Tunnel coded argument. That is to say that the more
> often an operator is used, make it cause the least amount of pain and
> physical damage. And I merge strings a lot in Perl.
On a typical US qwerty keyboard (yes, I'm being US-centric - feel free to
present other layouts), there are only 11 unshifted symbolic keys. Looking
at 751 (Perl) files within the Perl 5.6.1 library, a count of the symbols
used:
82045 '$'
44535 '('
44422 ')'
44033 ';' # Unshifted
40530 '=' # Unshifted
40485 '_'
35915 ',' # Unshifted
34559 '-' # Unshifted
33474 '#'
32833 '.' # Unshifted
32823 '>'
30855 '"'
29369 ':'
28106 "'" # Unshifted
25231 '{'
25212 '}'
16098 '<'
15058 '/' # Unshifted
14475 '\' # Unshifted
11739 '@'
6948 '[' # Unshifted
6749 ']' # Unshifted
6676 '%'
6052 '!'
5644 '&'
4672 '|'
4222 '*'
3788 '+'
2782 '?'
2715 '~'
2628 '^'
361 '`' # Unshifted
One of the reasons that '-' and '>' are so high is dereferencing. $a->[1]
and $a->method. I don't have a breakout of each character's use, though.
('.' as a sentence terminator, a decimal point, an 'anything' character, or
a concatenation operator, for instance. However, it *still* appeared fewer
times than an underscore.)
Most of the unshifted characters already have a standardized use in computer
languages. Otherwise, [] instead of (), or maybe `` instead of "".
b) I do not like the idea that you must have a space before the
> underscore so that it is not lumped into the variable name.
> i.e. $a=$b_$c; is wrong. You must type $a=$b _$c
> $a_=$b; is wrong. You must type $a _=$b;
>
> Even though it is a little cramped, sometimes I code that way. Perl5
> lets me put that operator right up next to the variable and I want Perl6
> to allow it as well. I have looked at tons of other programmers code
> and most do this and take it for granted. And be honest with a quick
> look above can you see the difference.
>
> c) Because of reason b. I find a little comfort in thinking of the
> string concatenation operator as " _" that is a space followed by the
> underscore. That way I could apply that rule universally. And then I
> thought of the RFC 082 section of Apocalypse3 and hyper operators.
> Because if it eases your mind to think of it as " _", then to be
> consistent the hyper operator should be "^ _" not "^_".
> i.e. @a=@b^_@c; Correct according to apocalypse 3, but what
> happened to the space
> @a=@b$ _@c; Super ugly but would be consistent;
> @a^_=@b; O man, can it get worse
> @a^ _=@b; Why, yes it can. Looks like the makings of a
> neat regex, just throw an "s" or "m" in front.
Except that the operator truly is simply an underscore. But it's also a
valid identifier character, so where it may be confused with that, you are
simply required to make it less ambiguous to the parser.
$a _= $b _ $c; # $a _= $b _$c;
${a}_=${b}_$c;
%h{$s}_="Hello, "_"world!\n";
As Larry said, no different that the other operators that also consist of
valid character identifiers.
Now granted, in some of those cases, misparsing would result in a syntax
error. But that still is ambiguous? Is the '_' supposed to be the
operator? Was the actual operator accidentally omitted?
>
> d) To me the underscore represents something special. Like the
> variables $_, or @_, __DATA__ not string concatenation.
>
>
> possible solution :
>
> I listed out characters to me that mean concatenate or merge.
> Here is the list:
> a) & "AND". Great, However it denotes a subroutine in perl.
And bit-wise '&'. (Not used very much in the Perl core, granted, but used
elsewhere nonetheless.) (And it's shifted, BTW.)
> b) + "ADD" or "PLUS". Read somewhere in the camel book that
> concatenation strings is not adding. and would confuse the math.
Yes. (And it's shifted, BTW.)
> c) - "Hyphen". When pronounced hyphen it sounds great. When
> pronounced minus ... well that won't work.
The same mathematical problems as '+', in both its binary and unary form.
Plus it's a range operator within a character class.
>
> Then I thought of it. In school whenever I separated a single word
> into two words my paper would come back with a small red arch joining
> the two words together into one. Of course that symbol was usually
> followed by a -5 or something like that. So I scanned the keyboard for
> something that looked like that small arch. Then I found it. The "^"
> symbol. Since I have a problem with the hyper operator idea, Maybe it
> could be used here. But what about xor. I can honestly say I have
> never used "^" to mean xor. The Huffman coded concept should make the
> use of xor rather than "^" a viable alternative. I read through
> Apocolypse3 and saw this justification:
IIRC, '^' was considered earlier. (And it's shifted, BTW.)
--
Bryan C. Warnock
[EMAIL PROTECTED]
