Re^8: what would you like to see in perl5.12?

[blazar]

is just breathless hot air admiration, but completely orthogonal to the point I was making.

First of all ++, because I saw your post in Worst Nodes, and I don't think it deserves being, since however may I disagree with it, it's well written and thought

[...] inside one of those long-winded substitutes for the simple quote-like operators that we already have. (And that no doubt Perl6Critic will adjudge it to being the moral equivalent of walking around with your fly unbuttoned if you don't use the long form; and a few individuals will adopt derigeur because they think it looks cute :)

(emphasis added by me)

I can't understand what you want to imply with the contraposition of "long-winded" and "long form" on one side and "simple" on the other one. I don't see how "..." and '...' are more complex than err, well, "..." and '...' respectively, with just the former having in Perl 6 some more and more reasonable interpolating power.

Is it that bad that in addition to

my $email = $user . '@location.wtf';

or

my $email = "$user\@location.wtf";

I can also write

my $email = qs($[e-mail]);  # ?

Personally, I find it very clear and perhaps the least confusing of the three.

And it will be impossible for editors, even those that are thinly disguised OSs, to highlight the difference between the passive and active bits. Ie. They will be unable to assist the (maintenance) programmer in working out which bits of string constants are actually constant and which are not.

I am fond of syntax highlighting: indeed I have set up an association in my editor for certain extensions and when I happen to mistype the latter on launching sometimes I start writing and only after a few lines do I realize I did, as if awakening from a dream while saying: is this stuff that I've written Perl? But as I wrote, personally I don't find that kind of assistance from the editor to be particularly valuable. Indeed if it highlighted variables interpolated into strings it would be distracting for me: just too many colors dancing in front of me. To each his own I suppose.

Anyway nothing but perl can parse Perl, and although Perl 6 is more orthogonal and consistent than Perl 5, this is not going to change. Indeed it will be promoted to: nothing but Perl can parse Perl. So no editor will ever do a perfect job of Perl syntax highlighting, but it may come close. Yours may just highlight {...} blocks: you may stick to that and your editor do a decent hob with them. OTOH I've heard rumors about the possibility of a perl interpreter to editor/ide communication for better management including syntax highlighting and other stuff.

I can see myself adopting the use of single quoted constants interspersed with concatenated variables and expressions, in order to make it clear what is constant and what not. So complex have the rules become.

For simple strings the rules are more or less as they are. The added complexity in more general cases is not that much, and anyway doesn't come at a price not worth the gain...

[BrowserUk]

I can't understand what you want to imply with the contraposition of "long-winded" and "long form" on one side and "simple" on the other one.

I simply meant that your discussion about (and enthusiasm for) the new longs forms

Q :q //    Q :qq //    Q :regex // Q :subst ///    Q :trans ///

was completely orthogonal to (ie. had no bearing upon) the what I was discussing in the post to which you replied, as I was discussing what is allowed to appear inside (one of) those forms.

I also (incidently) implied that I could see no practical benefit of those new long forms over the existing long forms:

q//   qq//   qr//    s///    tr///

with a little gently sarcastic humour.

But this was, and is, incidental to my main point that you were discussing a different issue to that which I raised. Which, for the record was: Those active constructs that may appear inside double-quoted literals, (and by implication, the long form(s) of double-quoted literals).

Now to the point about syntax highlighting. Here is a short script I knocked up in response to a recent SoPW, as it gets displayed here at PM:

Example 1.

#! perl -slw
use strict;
use LWP::Simple;

our $area ||= 1040;

my $url = "http://www.bbc.co.uk/weather/5day.shtml?id=$area"
+;

our $f;
my $html = $f
    ? do{ local( $/, @ARGV ) = ( undef, 'weather.failed' ); <> }
    : get $url or die "Failed to get html: $!, $?, $^E"
;

my $reTag = qr[< [^>]+ > \s*? ]x;
my( $place, $state, $temp, $wDir, $wSpeed, $humid, $press, $updown, $v
+is,
    $lat, $long, $date, $time, $TZ, $other #
) = $html =~ m[
    5\sDay\sForecast\sin\sCelsius\sfor\s+ ( [^<]+ ) .+?
    Current\s+Nearest\s+Observations $reTag : $reTag+
    ( [^<]+ ) $reTag \s+ ( \d+ ) .+?
    ( [NSEWA/]+ ) \s+ \( ( \d+ ) .+?
    Relative\s+Humidity .+? : \s+ ( \d+ ) .+?
    Pressure .+? : \s+ ( \d+ ), \s+ ( \S+ ) , .+?
    Visibility .+? : \s+ ( [^<]+ )
    .+?
    Latitude $reTag : \s+ ( [\d.-]+ ) , .+?
    Longitude $reTag : \s+ ( [\d.-]+ ) \. .+?
    Observed $reTag : \s+ ( .+? ) \s+ at \s+
    $reTag ( \S+ ) \s+ $reTag
    \( $reTag ( [A-Z]+ )
#    ( .{100} )
]smx or warn 'Regex failed!' and getstore $url, 'weather.failed';

print <<EOP;
For: $place
Sky: $state
Temp: $temp
Wind Direction: $wDir Speed: $wSpeed
Humidity: $humid%
Pressure: $press $updown
Visibility: $vis
Latitude: $lat
Longitude: $long
Observed: $date $time $TZ
EOP

And here is that same script as I see in my editor (as near as I can replicate that here at PM*): (*) Which was nightmarishly hard and I never did find any way to show comments/shebangs with a grey background?

Example 2.

#! perl -slw
use strict;
use LWP::Simple;

our $area ||= 1040;

my $url = "http://www.bbc.co.uk/weather/5day.shtml?id=$area";

our $f;
my $html = $f
    ? do{ local( $/, @ARGV ) = ( undef, 'weather.failed' ); <> }
    : get $url or die "Failed to get html: $!, $?, $^E"
;

my $reTag = qr[< [^>]+ > \s*? ]x;
my( $place, $state, $temp, $wDir, $wSpeed, $humid, $press, $updown, $vis,
    $lat, $long, $date, $time, $TZ, $other #
) = $html =~ m[
    5\sDay\sForecast\sin\sCelsius\sfor\s+ ( [^<]+ ) .+?
    Current\s+Nearest\s+Observations $reTag : $reTag+
    ( [^<]+ ) $reTag \s+ ( \d+ ) .+?
    ( [NSEWA/]+ ) \s+ \( ( \d+ ) .+?
    Relative\s+Humidity .+? : \s+ ( \d+ ) .+?
    Pressure .+? : \s+ ( \d+ ), \s+ ( \S+ ) , .+?
    Visibility .+? : \s+ ( [^<]+ )
    .+?
    Latitude $reTag : \s+ ( [\d.-]+ ) , .+?
    Longitude $reTag : \s+ ( [\d.-]+ ) \. .+?
    Observed $reTag : \s+ ( .+? ) \s+ at \s+
    $reTag ( \S+ ) \s+ $reTag
    \( $reTag ( [A-Z]+ )
#    ( .{100} )
]smx or warn 'Regex failed!' and getstore $url, 'weather.failed';

print <<EOP;
For: $place
Sky: $state
Temp: $temp
Wind Direction: $wDir Speed: $wSpeed
Humidity: $humid%
Pressure: $press $updown
Visibility: $vis
Latitude: $lat
Longitude: $long
Observed: $date $time $TZ
EOP

And this is how I would like to see it:

Example 3.

#! perl -slw
use strict;
use LWP::Simple;

our $area ||= 1040;

my $url = "http://www.bbc.co.uk/weather/5day.shtml?id=$area";

our $f;
my $html = $f
    ? do{ local( $/, @ARGV ) = ( undef, 'weather.failed' ); <> }
    : get $url or die "Failed to get html: $!, $?, $^E"
;

my $reTag = qr[< [^>\+ > \s*? ]x;
my( $place, $state, $temp, $wDir, $wSpeed, $humid, $press, $updown, $vis,
    $lat, $long, $date, $time, $TZ, $other #
) = $html =~ m[
    5\sDay\sForecast\sin\sCelsius\sfor\s+ ( [^<]+ ) .+?
    Current\s+Nearest\s+Observations $reTag : $reTag+
    ( [^<]+ ) $reTag \s+ ( \d+ ) .+?
    ( [NSEWA/]+ ) \s+ \( ( \d+ ) .+?
    Relative\s+Humidity .+? : \s+ ( \d+ ) .+?
    Pressure .+? : \s+ ( \d+ ), \s+ ( \S+ ) , .+?
    Visibility .+? : \s+ ( [^<]+ )
    .+?
    Latitude $reTag : \s+ ( [\d.-]+ ) , .+?
    Longitude $reTag : \s+ ( [\d.-]+ ) \. .+?
    Observed $reTag : \s+ ( .+? ) \s+ at \s+
    $reTag ( \S+ ) \s+ $reTag
    \( $reTag ( [A-Z]+ )
#    ( .{100} )
]smx or warn 'Regex failed!' and getstore $url, 'weather.failed';

print <<EOP;
For: $place
Sky: $state
Temp: $temp
Wind Direction: $wDir Speed: $wSpeed
Humidity: $humid%
Pressure: $press $updown
Visibility: $vis
Latitude: $lat
Longitude: $long
Observed: $date $time $TZ
EOP

Notice how the interpolated variables within the double-quote, regex and heredoc are (minimally) highlighted in the same way as variables outside of quote constructs.

As you can see, whilst I think syntax highlighting is a great boon to programmers, my tastes in how much/how many colours are used is pretty conservative compared to some psychedelic schemes you see around the web. For example, I see little benefit in picking out sigils in a different colour to the identifiers they are part of.

At this point, my argument leaves itself open to vagaries of peoples (your) personal preferences, which is the downfall of many a good argument, but I think that:

• the latter is far easier to scan and read than its precedent.
• which in turn, is far easier to scan and read than the standard PM view.

And it is all very well saying that Perl 6 will be able to parse Perl 6, and that maybe some editor will be written to use that to allow better syntax recognition, but given the divisive arguments about editors, and the range of configurations used by individuals within each of the individual editors, it is naive to believe that everyone, or even a reasonable percent of someones are going to adopt a new editor just to use Perl 6.

So, getting back to the original point, if you agree with me that the highlighting in the last example above is a positive boon to the readability of the code, then it would be very nice if it were possible to achieve that using Perl 5.12 (or Perl 6) within the auspices of the majority of existing editors.

If 5.12 (or Perl 6) offered a single construct that was easily recognised that could be used to embed a generic interpolation vehicle (a closure) within which any perl expression could be interpolated--as exampled by Perl 6s "...( code here }..." construct--then many editors would have no trouble recognising these and achieving the example 3 level of highlighting.

Final Perl 6 comment. Having recognised the utility and flexibility of the interpolated closure, I really do wonder why all the others are thought to be necessary? This seems to me to be a case where both the loading on the programmers memory, and complexity of the parser could have been greatly simplified by the use of Carters Compass. By the simple extension of the adverb construct so that they could be applied to the interpolated closure, it seems to me that all the other mechanisms could be done away with.