Macros arguments expansion around dot

[fmafma]

Macros arguments behave oddly when used in conjunction with '.':

    MACRO M_TOTO arg
        LD HL,blah.arg
    ENDM

    M_TOTO argValue

LD HL,blah.arg is expanded as LD HL,blah.arg instead if blah.argValue. Instead, it needs to be written:

    MACRO M_TOTO arg
        LD HL,blah._arg
    ENDM

    M_TOTO argValue

but this is not great, as it force to use an additionnal _ in front of argValue definition.

Same:

    MACRO M_TOTO arg
        LD HL,arg.blah
    ENDM

    M_TOTO argValue

does not expand correctly. Here, a simple fix is to do:

    MACRO M_TOTO arg_
        LD HL,arg_.blah
    ENDM

    M_TOTO argValue

and it works, whithout forcing an additionnal _, as it is added locally in the macro. Unfortunately, this does not work by prefixing macro argument with a _.

If there is no technical reason to forbid argument expansion around . (dot), it would be nice to correct this. Thanks!

[fmafma]

Adding (optional?) usage of {} around arguments could solve the problem:

    MACRO M_TOTO arg
        LD HL,blah.{arg}
    ENDM

    M_TOTO argValue

[ped7g]

sub-word substitution currently works only for id delimited by underscore, ie. ID1_ID2 and the underscore is part of the result too.
The dot char is not part of the id IIRC.

So your original idea to get blah.argValue is not supported at this moment.

The {} is unlikely to happen, it already works as virtual memory content reader and struct initializer list delimiter, I think this would become ambiguous in some edge case.

Do you need the dot there because the result is addressing some main.local label or structure member, so you can't change to underscore instead of dot I guess?

[fmafma]

Yes, I would like to access main.local labels, or even module.main labels.

I suggested {}, but it could be another syntax. Doubling them {{arg}}, maybe?

[ped7g]

so far I somewhat like the idea from #246 of standalone operator _ during substitution (preprocess) phase... until I figure out what's wrong about that one. {{... is still how struct initializers may look, so I'm not convinced. But it's an option, written down, so ... let's see what will happen (most likely nothing anytime soon, but eventually or when somebody else get more active... :) )