Re: [perl #45857] [IMCC][RFC] #line vs .line

Klaas-Jan Stol via RT wrote:
> On Thu Dec 13 04:35:13 2007, pmichaud wrote:
>   
>> On Sat Sep 29 08:57:28 2007, kjs wrote:
>>     
>>> A few months ago, the "#line" directive was implemented.
>>>
>>> I'm wondering what the reason was why it looks like a comment (as # 
>>>       
> will
>   
>>> start a comment).
>>> Is there any reason to not replace this by ".line"? A directive 
>>>       
> typically
>   
>>> tells the assembler/compiler something, and in this case it updates
>>>       
>> the line
>>     
>>> number.
>>>       
>> As this gets addressed we should also address the handling of the
>> 'setline' opcode (RT #43269).
>>
>> Pm
>>     
>
>
> .line directive is implemented per r33084. #line still works.
>
> I'm not sure what Pm meant by addressing the handling of 'setline' 
> opcode, so leaving this ticket open.
>
>   
I'm planning to work on bytecode annotations Real Soon Now...my thoughts 
on these issues are:

* I think .line and .file will remain for setting the PIR-level line and 
file (#line and #file maybe too, or we could deprecate those)

* .annotate "key" value / .annotate "key" "value" will be added for 
setting annotations, which will form high level language debug info 
(.line and .file may be converted to also store data using the new 
annotations segment rather than keeping a separate PIR debug segment in 
the future; not sure how soon that will happen, will leave the current 
debug seg intact for now though)

* setline and setfile opcodes can probably go away; I can't think of a 
use case where we'd want to set these dynamically, since we know the 
line number/file number/column/whatever else we wish to store at compile 
time. Doing an op dispatch rather than making an annotation we can look 
up only when we need it seems odd to me.

Thoughts?

Jonathan