http://qs321.pair.com?node_id=634003


in reply to what would you like to see in perl5.12?


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.

Replies are listed 'Best First'.
Re^2: what would you like to see in perl5.12?
by duff (Parson) on Aug 21, 2007 at 14:23 UTC

    Forget that ... what would be really nice would be the ability to interpolate *anything* into a string. As in Perl 6:

    print "Hello, my name is {some_expression_generating_name();} and I'm +here to help.";
    Sure, it makes the curly braces special, but that's a small price to pay compared to the benefit IMHO.

      Actually yes. That would solve this problem, and several other similar ones.

      Given that whatever was put in place would have to remain notionally backwards compatible--which probably means any new interpolation mechanism is a non-starter but---I'd probably go with:

      "some stuff {{ any perl expression here }} more stuff"

      Indeed, if I'd been spec'ing Perl 6 interpolation, I think I would have removed all other interpolations in favour of a single 'interpret the block and substitute whatever it produces in its place' construct.

      It mildly complicates the simple case " xxx{{ $var }}xxx" instead of "xxx${var}xxx", but in the general case, it would be no more complicated than "xxx@ary[]xxx" or "xxx%hash{}xxx", and the consistancy would greatly simplify the parser.

      Indeed, the parsing would become simple enough that most editor syntax highligher parsers would probably be able to pick out embedded interpolation blocks, making them stand out from the surrounding string, and even highlight the embedded code in the usual manner.

      For me, the ability to have my editor highlight interpolations, (without resorting to running a second OS as an editor:), would more than make up for the slightly less convenient syntax it would require for the simple case.


      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.
        Indeed, if I'd been spec'ing Perl 6 interpolation, I think I would have removed all other interpolations in favour of a single 'interpret the block and substitute whatever it produces in its place' construct.

        Oh no! Perl 6's new quoting mechanism, with everything based on a single C<Q> and a bunch of adverbs is just breathtaking: it is at same time simple, intuitive and powerful as familiar constructs like C<q> and C<qq> will remain very much the same as in Perl 5 and a terrible amount of more flexibility will be available at the tiny expense of appending a semicolon and a few letters. Or in some cases no colon at all and a single letter.

        For me, the ability to have my editor highlight interpolations, (without resorting to running a second OS as an editor:), would more than make up for the slightly less convenient syntax it would require for the simple case.

        Oh well, that's hardly a problem for me so we definitely see things from two very different perspectives. Personally, I find too much syntax highlighting to be distracting, but when I find it... ehm... desirable. (Speaking of strings, in current Perl, e.g. when the necessary evil of a string eval of a considerable amount of code is needed and then I use q{...} or qq{...}.)

        Yet it seems to me we could still have the best of both worlds: if e.g. C<qq> implies :s, :a, :h, :f, :c and :b you may still stick to only interpolate {...} expressions when you want them to be syntax highlighted, and your editor may do a good job of doing so.

        Or if you want to stay very strict, then you may get into the habit of doing:

        macro qbuk { Q:c:b }
Re^2: what would you like to see in perl5.12?
by blazar (Canon) on Aug 21, 2007 at 09:29 UTC
    Perhaps using "some stuff %{hash} more stuff"; producing the same effect as print 'some stuff ' . %hash . ' more stuff';

    Are you sure? Do you know what the value of a hash currently is in scalar context?

    campari:~ [11:27:54]$ perl -MData::Dumper -le 'print "<" . %INC . ">"' <5/16>
Re^2: what would you like to see in perl5.12?
by ysth (Canon) on Aug 21, 2007 at 05:50 UTC
    Do you have a use case in mind? Given the lack of order of keys and the alternation of keys and values, I can't come up with one.

      The really simple one of checking what is going on in the hash when debugging.

      It would be even better if the formatting was a little more sophisticated than just a space separated list. Say key1:value1 key2:value2 key3:value3, but that's a nicety.

      Just as with the default interpolation of hashes in Perl 6, if you need more sophisticated layout, sorting etc. then it's back to rolling your own or using a dumper, but sometimes you just want a quick check. Currently I would use the "@{[ %hash ]}", but a simpler syntax would be good if it could be made to work.

      No biggy, but the thought crossed my mind.


      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.
Re^2: what would you like to see in perl5.12?
by phaylon (Curate) on Aug 07, 2008 at 13:53 UTC
    Wouldn't that break lots of (s)printf formats?

    Ordinary morality is for ordinary people. -- Aleister Crowley

      As I originally proposed it, I don't think it would. In any legal printf format, % is followed one of %*+- #csduoxefgXEGbpniDUOF\d..

      Which I think means that %{...} would not conflict with any existing formats, and would generate: Invalid conversion in printf: "%{" if it appeared in any existing code. The lack of backwards compatibility issues is the nice thing about that original proposal. Albeit that I'd extend/mutate my original proposal to encompass some of the further discussion it generated.

      It can easily be extended to make %{...} a generic, interpolate whatever is inside this embedded code block and convert the result to a string in the default manner.

      And that could further be extended in a manner in keeping with normal printf rules so that it can become: %fw.p{...} where the f, w & p follow the same rules for flags, width & precision as are applied to the standard s specifier.

      To simplify: %fw.p{xxx} acts pretty much like:

      printf "%fw.ps", "@{[xxx]}"

      The code xxx is evaluated, the result converted to as string, and the string substituted as if %s had been used.


      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.
        printf "%{" is legal, and prints %{. With warnings on, it does issue a warning, but it's (currently) not illegal.

        But your initial proposal talked about interpolating in strings, and in strings, "%{hash}" is currently fine. No warnings. I'd be more worried about regular strings 'breaking' than any (s)printf formats.