Yes, it's easy to have a great deal of affection for the current syntax. It seemed like a good idea at the time, and still works pretty well in the context of the rest of Perl 5. But to some extent you have to take it on faith that we didn't change anything without at least the semblance of a good reason, and many of these reasons make more sense in the context of Perl 6 as a whole. I can attempt to explain some of those decisions here, but I can't rejustify every decision, or I'd end up copying all the Apocalypses, Exegeses, Synopses into Perl Monks, not to mention replicating a great number of design meetings, phone logs, irc chats, etc. And as chromatic points out, we'd never get any work done if we tried to answer every question multiple times.
However, I have some hope that this thread will have sufficient cultural leverage to make a difference, so I'm responding here. On your particular points:
for =$fh - that just looks string. I think while(<$fh>) is too strong of idiom to break
Brackets are in extremely short supply in ASCII, and the angle brackets were rather wasted on a single operator. Plus we really needed to do something about the strange autoquoting rules in subscripts that result in far too many FAQs. Stealing angles for both qw// and literal subscripts solved those problems, but it meant that we needed something else to iterate iterators. And unary = is the best we've come up with so far, given all the other demands on the character set. It has some visual mnemonic value in that it looks kinda like two lines from a file. But yes, it's a little strange.
~ ~ for string concats
We needed something for that operator, and dot was no longer going to be available. We can't use juxtaposition like awk because that screws up expectations of terms vs operators, a fundamental contextual idea that carries through all the way from Perl 1 to Perl 6. We originally specced _ for it, but it didn't work well next to identifiers, and we wanted to reserve the underscore identifier for other potential uses, so we settled on ~ because it looks like a bit of string, and because the bitwise uses of tilde were going away in favor of a de-Huffmanized but more regular set of bit operators, so tilde was available.
??!! replacing ? :
This is another case where some very important keys on the keyboard are locked up in not-so-very important operator, so we decided to de-Huffmanize and rationalize them.
(The use of a bare colon was particularly difficult because there were so many other proposed uses for colon that we were trying to accomodate.)
The character doubling fits in culturally with the other short-circuiting forms such as && and ||. At one point the else was indicated by a double colon, but that turned out to be visually ambiguous with package name delimiters, plus we have a fairly consistent usage of ? to mean true and ! to mean false through the rest of the language.
Anyway, you undoubtedly like the current Perl 5 idioms for the same reasons that I liked them originally. :-) I would like to believe that you'll end up liking the Perl 6 idioms too, once you get used to them. | [reply]
[d/l]
[select] |
Stealing angles for both qw// and literal subscripts solved those problems, but it meant that we needed something else to iterate iterators. And unary = is the best we've come up with so far, given all the other demands on the character set. It has some visual mnemonic value in that it looks kinda like two lines from a file. But yes, it's a little strange.
Reusing angle brackets was a great idea. I really like being able to write stuff like:
my @array = < foo bar baz >; # instead of qw/ foo bar baz /
%hash<foo>; # instead of %hash{'foo'}
But I also agree that the unary = is a bit strange.
(On the other hand, qw// was a *very* strange idiom -- so I believe that, overall, Perl6 is a bit less strange beast.)
| [reply]
[d/l] |
??!! replacing ? :
I know this is completely OT in the context of this thread, but I've not been in p6l for a long time and I'm trying my hand here. Now, I've sometimes felt the need to distinguish in a single statement between "TRUE", "FALSE" and "UNDEFINED". To this effect in Perl 5 I've had to use nested ?:'s or other short circuiting operators, with an overall "too much effort" back taste. I was wondering if by any chance Perl 6 could incorporate unambiguously in ??!! an optional additional !! so that the fourth argument is returned in case the condition turns out to be undefined.
| [reply]
[d/l]
[select] |
Indeed a particular syntax can have a strong influence on us.
Why, just the other day I almost typed 'sub' into a PHP source. (It's 'function' there.) Two reasons I really wanted to learn C when I was starting out in programming was because '{' and '}' were much quicker to type than 'begin' and 'end' and they also were more visually distinct from functions. I often want to use curly brackets for associative arrays in PHP (square brackets there). I often try to use foreach in JavaScript (It never seems to work). In JavaScript, I sometimes try concatenating strings with '.' and using '+ 0' (as opposed to '- 0' which doesn't have precedence issues from overloading) to coerce numeric context.
Oddly enough, after a couple of minutes with the code at hand I remember what language I'm using. After that point, the right spelling for the language I'm using tends to come back to me pretty easily and I'm on my way.
I have faith my transition to Perl 6 will be no easier but probably not much harder. I'll try Perl 5 in Perl 6. I'll go back to a Perl 5 project and try Perl 6 syntax. Of this I have no doubts. After a few minutes with one or the other, though, I'm sure I'll get in the groove of that particular dialect.
| [reply] |
