Version 11 (modified by japhb, 4 years ago)

Add notes about closure interpolation and whitespace/paren issues

Migrating to NQP-rx

This page presumes that you have some already-written NQP code, and you are converting it to NQP-rx after the 1.8.0 upgrade.

Here are the things I have found so far:

$-variable and { ... } interpolation in double-quoted strings.

I have been using qq strings because they allow backslash-interpolation, but because a bunch of my stuff generates PIR on the fly, I have " ... $P0 ... " all over the place. Needless to say, this is generating a fair amount of rework. Similarly, { } within double-quoted strings will be treated as a closure interpolation, expecting valid NQP code between the curly braces.

Loading Parrot Bytecode

All uses of 'load_bytecode' need to be replaced by 'pir::load_bytecode'.

Stricter POD syntax

I haven't dug into the code for the new rules, but the current POD recognizer is more picky than it used to be. Formerly, the POD parser took just about any set of ^= lines as POD. (And I took horrible advantage of that.) Now, I'm not sure what it's doing. (For myself, I'm just converting everything to # comments.)

Lexical subs

I've read this in Pmichaud's release notes, but I haven't had the chance to bounce off it yet (because I'm still working on the issues above). This will make a difference in code that has been doing Foo::bar() style calls, since apparently bar() will now require "our sub bar" instead of "sub bar". That doesn't seem too bad, considering the other changes. More as it becomes relevant.

Spaces before postfix operators disallowed

I had some code like $x ++; and $x --; that failed. Removed spaces.

Stricter whitespace rules around keywords

if $condition { } else {} now requires spaces around the else keyword. Similarly if( $condition ) { must be replaced with if ( $condition ) { or if ($condition) { or (idiomatically) if $condition {. This applies to unless, while, until, for, and so on as well.

Parameter initialization

A parameter like: sub foo( :@tags? ) -- that is, an optional, named, array -- is now initialized to an empty RPA if no value was provided. (Previously, the default value was Undef.) This merges two possible cases from the caller side: not specifying a value, and specifying an empty array. Code that depends on this will have to change.

This same type of change is likely present for hashes, as well. I'm guessing this applies to any hash/array parameter.

Globals not adequately vivified

I noticed a bug in our variable vivification (#1308). In essence, a sub referencing a global variable does not have viv code inserted, so the global had better be defined on entry, or you need to use the pir::opcodes to check it, or you need to be doing a blind initialization.