I had problems to see why dereferencing should be implemented with a block syntax, but indeed one is free to include any statement inside %{...} as long as it can't be confused with a variable

for instance

  DB<2> print %{ ( do{ {A=>1} } ) }
A1
[download]

Actually the problem is not restricted to dereferencing. other block syntax is having the same impact of messing up "nextstate".

Like this

   print_calling_line( __LINE__,
                       do { A => 1, B => 2, C => 3 }
                     );
[download]

will report the line of the do statement.

update

actually the line of the last block will be reported

   print_calling_line( __LINE__,
                       do { A => 1, B => 2, C => 3 },
                       do { A => 1, B => 2, C => 3 },
                       do { A => 1, B => 2, C => 3 }
                     );
...
Called from line 27; caller() reports line 30
[download]

looks like the line number is stored inside a localized variable in C and overwritten while parsing following blocks.

It looks like some block statements report the line the block begins—dereferences, as in my OP, as well as calls to do and eval (block style only!)—but others, notably inline creation of an anonymous subroutine with sub { }, report the line after the block (???). I haven't messed around with the decompiler, but I assume this has to do with where the nextstate elements get placed.

Example:

Read more... (1516 Bytes)

> report the line after the block (???).

ugh ... oO

I'm pretty sure there is some global variable supposed to hold the line number getting overwritten while descending the arguments tree.

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)
Je suis Charlie!}