[Feature request] Allow PRINT to accept VARPTR for ROM string printing

[fmaida]

I understand that RAM space is precious and we must store as much as possible in the ROM.
Actually if I want to print a constant string with my name, I'm using:

#ptr = VARPTR name(0)
#col = 0
WHILE PEEK(#ptr) <> 0
    PRINT AT #col, CHR$(PEEK(#ptr))
    #ptr = #ptr + 1
    #col = #col + 1
WEND

name:
    DATA BYTE "Francesco", 0

I get most of the logic behind this code: I need to point to the memory location where my constant string is located and print each byte on screen until I reach a value of zero.

I've never been good at working with pointers in C, so please pardon me if this is a stupid idea, but wouldn't it be easier to read and slightly more high-level if I could write a constant string from ROM like this?

PRINT AT 0, VARPTR name

name:
    DATA BYTE "Francesco", 0

Just for the sake of curiosity I tried to compile this code with CVBasic (targeting MSX). The compilation reports no errors, but then the assembler throws what looks like an internal error:

CVBasic compiler v0.9.1 Feb/17/2026
(c) 2024-2025 Oscar Toledo G. https://nanochess.org/

1 RAM bytes used of 4782 bytes available.
Compilation finished for MSX.

Error: Redefined label 'CVB_NAME' at line 4425

As a further thought, an even more BASIC-friendly syntax, if this is ever possible, could be:

CONST NAME$ = "Francesco"

PRINT AT 0, NAME$

Where the compiler handles the ROM placement and pointer resolution internally, without exposing pointer mechanics to the programmer at all.

For example, your compiler could recognize the CONST keyword and then a variable name that ends with a dollar sign and build a label like this:

NAME__string:
    DATA BYTE "Francesco", 0

Then, whenever PRINT AT 0, NAME$ is encountered, the compiler could inject a single shared subroutine once and reuse it for every string print in the program.

I'm just asking if this could be a good idea and if it is, maybe someday this might be implemented in the compiler, of course only if it's not too complex to implement.