Re(3): Perl 6 Whitespace Issues

[Ovid]

After reading through Apocalypse 12, I finally started to get a handle on Abigail-II's concern, but I can't buy the argument. The vast majority of Perl code that I see does not use whitespace in quite the way Abigail-II does:

%hash {foo} = 'bar'; # illegal in Perl 6, as Abigail points out

# versus:

%hash{foo} = 'bar'; # what the rest of the world does

Admittedly, some people might find this to be a minor annoyance. Further, sometimes programmers do what Abigail does when trying to format a bunch of variables neatly. However, you can get around that if you really need to (IIRC):

%hash .{foo} = 'bar'; # note the dot

This minor inconvenience seems a small price to pay for the benefits we gain. Many of those benefits, in fact, are involved with giving Perl a powerful, robust OO model. This is one of Abigail's main complaints about Perl 5 -- and a reasonable one at that -- so I'm rather suprised that there's not more acceptance of the minor inconvenience. That's why I'm a bit confused about what Abigail's objections really are because I can't see this as being a serious issue.

[adrianh]

That's why I'm a bit confused about what Abigail's objections really are because I can't see this as being a serious issue.

I don't find the issue significant enough to discard the rest of Perl 6, but I have to admit it's one of the very few areas of the language that I really don't like.

Actually I don't find the {} issue a problem personally. The heuristic of no-space = hash, space = block matches my code style, and the style of the vast majority of code that I come across, so it's not going to cause me any major hassles.

The method argument stuff on the other hand I find much more personally problematical.

I've written code in goodness knows how many languages over the last 20 odd years so I'd like to think I'm vaguely broad minded when it comes to syntax, but when I see code like this:

a. $obj.method ($x + $y) + $z  # means $obj.method(($x + $y) + $z)
b. $obj.method($x + $y) + $z   # means $obj.method($x + $y) + $z
c. $obj.method + 1             # means ( $obj.method ) + 1
d. $obj.method +1              # means $obj.method( 1 )
e. $obj.method+1               # an error!

my intuitions and Larry's are obviously seriously mismatched since I'd get (a), (d) and (e) wrong unless I am expending effort to think about it. I've shown it to a few other developers than I know and they all got (a), (d) and (e) wrong too.

Now of course I can learn this syntax (and I'll probably have to :-) and the other interesting bits of Perl 6 mean that I'll still be giving the language some serious consideration - so why carry on about it.

A few reasons:

• Selfish first - I just don't like it!
• I don't see that the significant white space increases clarity or conciseness enough to justify the learning curve. The rules seem fairly arbitrary to me (hmmm... maybe this is the last point with more words)
• I want Perl 6 to be completely perfect and wonderful so I'm willing to spend some effort niggling about the little things :-)
• The reaction of the developers I explained the white space rules to was unanimous horror. I expect that "it has these completely unintuitative rules for white space" to become part of the standard Perl 6 FUDer's armamentarium .
• Perl 6 is a lot friendlier than Perl 5 to people coming from other languages except in this area of whitespace. I can't think of another language that has whitespace rules like this so it's going to make the learning curve nastier.
• It's going to make switching the mental switch between Perl and Ruby/C/Lisp/Eiffel/Whatever and Perl harder for people like me who jump around between languages a fair bit.

Basically every programming language out there has trained my eyes to ignore white space except for indentation. The latter is why I don't mind languages like Python or occam because their white space rules are a match for the informal coding style I'd be using in any other language.

I'm going to have to retrain my eyes for Perl 6.

I'm not looking forward to it because I don't see any major advantage that these rules are going to give me as a developer

(Of course now is the time somebody will point out that there are some really nifty examples hidden in the depths of A12 - which I'll get around to reading properly Real Soon Now - which will probably result in a stupidly huge list of niggly comments that annoy everybody involved :-).

[TimToady]

Things are getting a little better. Under the most recent rules, case 'b' is the only one that is not an outright error. Method arguments must now be specified explicitly with parens or adverbs. I'll be posting more details to perl6-language about this soon.

[Abigail-II]

This minor inconvenience

It may look minor to you. But think how often you index in a hash in a typical program, and how often you call a method/subroutine on the LHS of an operator. All those minor inconveniences add up to one big inconvenience.

for the benefits we gain. Many of those benefits, in fact, are involved with giving Perl a powerful, robust OO model.

*blink* Then I must have understood the benefits of significant whitespace totally wrong. The hash index without whitespace gives us the ability to leave off parenthesis around an if clause. The sub/method whitespace rule gives us the ability to sometimes leave off parenthesis in an expression. It's completely unclear to me how the whitespace rules are being used to build an OO model.

I might be willing to accept the significant whitespace rules if there was a significant gain. So far, every gain I've seen explained involves the ability to leave of parenthesis.

Abigail

[ysth]

How do you feel about the %hash .{key} workaround? I think you are really in the minority, and asking you to slightly adapt your style makes sense there.

On the other issue, the GNU coding style calls for spaces between function name and parenthesized argument list, and is used by a great many people (though not by me except where required by local standards). I imagine there would be an uproar if perl6 were released only with a GPL incompatible license. I regret there isn't a similar uproar over this issue.

[Abigail-II]

How do you feel about the %hash .{key} workaround?

About as bad as %hash{key}. The dot there is unnatural, and doesn't make the code more clear.

I think you are really in the minority, and asking you to slightly adapt your style makes sense there.

Minority or not, that doesn't matter. Larry's view are clear - there's no chance in hell he's going to change his mind on this one. But for me it's a big deal - a very big deal, and it doesn't become a lesser deal whether I'm in the minority, the majority, or alone. For me the issue is big enough that I don't see myself ever programming in perl6, and hence I ain't going to "sell" perl6.

On the other issue, the GNU coding style calls for spaces between function name and parenthesized argument list

For me, there's hardly a difference between indexing in an array or hash, and calling a subroutine. And, from the point of the expression where the indexed element, or the subroutine value is used, there is no difference. Indexing in an array or hash is just a call to a subroutine with one argument. Which is why I put whitespace between an array or hash name and its index, and I put whitespace between a function name and its argument(s).

Abigail

[PhilHibbs]

On the other issue, the GNU coding style calls for spaces between function name and parenthesized argument list, and is used by a great many people (though not by me except where required by local standards). I imagine there would be an uproar if perl6 were released only with a GPL incompatible license. I regret there isn't a similar uproar over this issue.

Huh? The GNU coding style is not mandatory for GPL projects. It may be mandatory for GNU projects, but Perl is not part of the GNU Project, is it?