Hello all,
I have been using Perl for years. It is the language of choice for most
of my needs. This is my first time posting. I have read Apocalypse 3
and many of your responses.
Issues:
1) Binary _ or string concatenation
2) RFC 082: Arrays: Apply operators element-wise in a list context
3) Special variable representing index of array in foreach
structure "$#" maybe (not in apocalypse3, I think)
1) Binary _ or string concatenation
The thought of using "_" to concatenate strings is a little
disappointing to me.
reasons for the disappointment :
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.
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.
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.
b) + "ADD" or "PLUS". Read somewhere in the camel book that
concatenation strings is not adding. and would confuse the math.
c) - "Hyphen". When pronounced hyphen it sounds great. When
pronounced minus ... well that won't work.
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:
"However, Perl has a built-in xor operator, so this isn't really
much of an issue. And there's a lot to be said for forcing parentheses
in that last expression anyway, just for clarity. So unless anyone comes
up with a large objection that I'm not seeing, this RFC is accepted"
I like the idea of forcing me to use parentheses around xor more than
forcing me to put a space before an operator.
2) RFC 082: Arrays: Apply operators element-wise in a list context
(hyper operators)
and
3) Special variable representing index of array in foreach structure
"$#" maybe (not in apocolypse3, I think)
There are many times that hyper-operators would come in handy. And I
have prayed for the special index variable in foreach loops. At first
they both sounded like welcome additions to Perl. Then I started to
think about them. I am an engineer at heart. Granted I say I am a
programmer, but I am an engineer. When I saw hyper operators I was
excited. I thought to my self if you are going to allow that type of
operation what about all the other goodies that come along with Vector
and Matrix arithmetic. Dreams of multiplying a Jacobian
multidimensional array to an input vector array were dancing in my
head. I wonder what operator that would be.
Then I regained my composure and asked why do I really want these
things. I can do what I need in Perl5. This is why:
my @x=(1,2,3,4,5);
my @y=(2,3,4,5,6);
my @z=(4,5,6,7,8);
my @result;
my $index = 0;
for my $x (@x){
push(@result,$x+$y[$index]+$z[$index]);
$index++;
}
All of that just to add these three arrays together. You can see that
the auto index variable "$#" would make life easier.
my @x=(1,2,3,4,5);
my @y=(2,3,4,5,6);
my @z=(4,5,6,7,8);
my @result;
for my $x (@x){
push(@result,$x+$y[$#]+$z[$#]);
}
Easier, but not by much.
Then I thought for a while. Now this is only someplace to start and I
am sure that someone can think of something better. I got the idea
while thinking of the semicolon in the c-style "for" statement.
What if you could do this:
my @x=(1,2,3,4,5);
my @y=(2,3,4,5,6);
my @z=(4,5,6,7,8);
my @result;
for my ($x,$y,$z) (@x;@y;@z){
push(@result,$x+$y+$z);
}
and if you could do that why not this:
my @x=(1,2,3,4,5);
my @y=(2,3,4,5,6);
my @z=(4,5,6,7,8);
my @result=map{ $_[0] + $_[1] + $_[2]} (@x;@y;@z);
.. OR ..
my @result=map{ shift + shift + shift} (@x;@y;@z);
This may provide a more powerful solution to the problem than
hyper-operators. But may be more difficult to parse or code.
Erik Lechak
[EMAIL PROTECTED]
----------------------------------------------------
Sign Up for NetZero Platinum Today
Only $9.95 per month!
http://my.netzero.net/s/signup?r=platinum&refcd=PT97
