If you want to keep your current style you can write:

    $html ~= [~]
        createLink( $USER, "you" ),
        " have ",
        $new + $old,
        " message",
        1 == $new+$old ?? "" !! "s",
        " left";
[download]

    $html ~=
        createLink( $USER, "you" ) ~
        " have " ~
        $new + $old ~
        " message" ~
        (1 == $new+$old ? "" : "s") ~
        " left";
[download]

    $html ~= "{createLink $USER, "you"} have { $new + $old } message{"
+s" x ($new+$old == 1)} left";
[download]

    $html ~= 
    "{
        createLink $USER, "you"
     } have {
        $new + $old
     } message{
        "s" x ($new+$old == 1)
     } left";
[download]

    $html ~= "$USER.createLink("you") have &pl($new+$old,"message") le
+ft";
[download]

I've also come to dislike sprintf for such concatenations. I don't like the out-of-order nature between non-format-specifier parts of the first argument and the other items being concatenated into the result. And I don't like the separation between the format specs and the values being formatted. I've also seen too many mistakes like sprintf "bleh $foo%s bar", complex($expr) where $foo might contain a % character. In most cases I find that the majority of the parts are simply being concatenated so if any of the items need 'printf' formatting, then I use sprintf to format just that item:

$html .= join '',
    createLink( $USER, "you" ),
    " have a ",
    sprintf( "%+.2f", $rating ),
    " rating";

    $html ~= [~]
        createLink( $USER, "you" ),
        " have a ",
        $rating.fmt("%+.2f"),
        " rating";
[download]

    $html ~= "{createLink $USER, "you"} have a $rating.fmt("%+.2f") ra
+ting";
[download]

Which might lead to the suggestion of here-docs, which I really dislike since they can't be indented and can fail very confusingly in the face of invisible trailing whitespace.

I hope that leads to some to think of suggesting a "real" templating system. That's often an excellent suggestion. Of course it isn't an appropriate replacement for tons of cases of concatenation. (:

we fixed the precedence of concatenation with respect to + (at your suggestion)

Thanks! And you're welcome. ;)

I like your first example. It is nice to have a "concat this list" option so compactly.

One of the things that I really learned to like about join '', ... is how low the precedence of comma is, so I don't have to put parens around even 'the ternary'. I agree that ?? :: should bind looser than concatenation but that also means I probably won't be doing direct concatenation of long lists of expressions. (Which is not a problem since there are better options.)

And the rest of the options are lovely.

Well, we fixed the indent part at least, though you're still on your own with trailing whitespace.

I'll have to review the lastest proposal on handling of indenting as I wasn't sold on some of the previous versions. But why don't you ignore trailing whitespace after the delimiter? I've decided that it is almost always better to do s/\s+$// over chomp because trailing whitespace is invisible and really deserves to be ignored. Tell me which line has the extra leading space and which one has the extra trailing space:

    LINE
    LINE 
     LINE
    LINE
    LINE
[download]

Sure, you can do it, if you know to look specifically for it, but it just sucks to have things that break due to such. At the very least, Perl 6 should shout "I noticed you had trailing whitespace after what would have otherwise ended your here-doc, but I didn't ignore it and that is probably why I couldn't find the end of your string". (:

Is there some value to allowing trailing whitespace to make the delimiter not the delimiter? The only value I come up with is a way to include something that looks like the delimiter in the output. I'd much prefer that be done in a much more visible way. Using such a subtle trick deserves a comment pointing out what is going on. But it is worse because (having worked even in a small company where my editor actually shows me trailing whitespace) I know that lots of editing situations don't give trailing whitespace much respect. Lots of things strip it or add it with little justification.

Surely, several of the above interpolation techniques would be better methods for including a line equal to the delimiter in the here-doc:

my $string= <<END;
You end your here-doc with a line like:
{''}END
but be sure to prevent any trailing whitespace
from sneaking in!
END
[download]

What purpose am I missing?

- tye        

But why don't you ignore trailing whitespace after the delimiter?

We do. I was talking about trailing whitespace within the string.

my editor actually shows me trailing whitespace

I have my editor set to strip trailing whitespace on save for most filetypes and all 17 language filetypes I have it configured for.

Are there any languages where trailing whitespace can be significant? (Other than the above example.)

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

 $html ~= [~]
        createLink( $USER, "you" ),
        " have a ",
        $rating.fmt("%+.2f"),
        " rating";
[download]

Couldn't that be written as:

[~=] $html, createLink( $USER, "you" ), " have a ", $rating.fmt("%+.2f
+"), " rating";
[download]

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Nope, because that would come out to A ~= B ~= C ~= D, which would only work if assignment were left associative.

As is traditional, I disagee. I find this far clearer than any other option shown:

$html .= sprintf '%s have %d message%s left',
    createLink( $USER, "you" ),
    $new + $old,
    $new + $old == 1 ?  ''  :  's'
;
[download]

1. The general format (and the constant parts) of the message are clearly identifiable on the first line.
2. All the variable parts are clearly identified.
3. You have complete control over the formating.
   • Leading zeros. Hex/octal.
   • Graceful transition to sci notation if number get big or small.
   • Left/right justification if needed.
4. And it's a fully extensible construct that deals nicely with very long string too.

   $html .= sprintf '%s have %d message%s left'
         . ' occupying 0x%x %s of server space',
       createLink( $USER, "you" ),
       $new + $old,
       $new + $old == 1 ?  ''  :  's',
       $space, 
       $units,
   ;
   [download]

That should be %s have %s message%s left'. Using %d in perl is rarely the right thing to do:

$ perl -we'printf qq[%d\n], 3e9'
3000000000
$ ssh shaggy "perl -we'printf qq[%d\n], 3e9'"
-1294967296
[download]

%d is a C concept, and doesn't map well to Perl's pick-one-of-three possible formats to store a number.

%e/%f/%g are also not completely problem free, since they could end up losing precision on a 64 bit int/53 bit mantissa perl.

--
Online Fortune Cookie Search

I get where you are coming from, but the day a (perlmonks?) user has nine billion messages in the system, I think there will be slightly greater problems than a malformed informational message.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

I think the first example you give is quite nice.

I quite dislike your second example, however. I find it far too difficult to map between the too-many format specifiers spread (rather willy-nilly) over multiple lines and the unnumbered list of expressions below. If the format specifiers had numbers or names, then it would bother me less. I understand your point of disliking having the over-all format broken up.

I've run into enough cases quite a bit longer than your second example and just don't find that sprintf scales to such situations. It can make quite clear code for the small cases, but I dislike the risk of variables being interpretted directly into the format string (because I've seen it happen so often when sprintf is used) and especially don't like how it doesn't scale. So I quickly jump to the method that scales the best, and also produces quite readable code, IMHO.

- tye        

However, reading the code it strikes me there may be a more general approach. Name all final expression values and put them in variables. Then you can simply interpolate them in a qq string and be done with it.

As a bonus, it's more self documenting.

Also, from your example above, note how the duplication of $new + $old goes away.

I rarely generate HTML like this, but perhaps an argument can be made that the method and sub calls above (createLink, sprintf) are special enough to do something clever with the Interpolation module to be able to write something like this:

my $message_count = $new + $old;
$html .= "$createLink{$USER, "you"} have $message_count $plural_of{"me
+ssage", $message_count}";
[download]

(Escaping the HTML is left as an exercise for the reader, as is tradition)

/J

The repetition of $new+$old was an artifact of quickly fitting several demonstrations in a single example. I wouldn't jump to separating out such simple expressions that are only used once so that you have to use the variable names to mentally map a large number of items being combined to what they were set to. If an expression is more complex than the ones in my example, then introducing a named variable often makes sense.

But the benefit of a named variable usually depends heavily on the quality of the name. With such short expressions, the name of the variable is often going to be only slightly shorter and can be much less clear. I can put a lot of effort into coming up with names when coding. Great names versus unclear names makes an enormous difference in the clarity of code. So I'm not excited to introduce a new name for something so small as createLink($USER,'you') that is used only once.

And part of the point I was making with the example was how things scale when the code deserves to be split over multiple lines. I find this makes interpolation break down as far as code readability; that is, I don't like reading several lines of strings each with several named variables interpolated and above this a long list of variables being declared and initialized. For example, it makes it hard to notice that you are doing work to assign a value to a variable that you are actually no longer using below.

As for Interpolation.pm, you don't show how much code has to be added to create %createLink and %plural_of and then has to be understood. A function or method like createLink() is a general-purpose abstraction while you wouldn't define just %createLink and only use it, avoiding the duplication of making a createLink(). So I've never gone that route. But since interpolating into strings also doesn't scale well for me, that isn't surprising.

- tye