Nested local labels

[fmafma]

How hard would it be to implement nested local labels?

The idea is to be able to write:

label1

.local1  ; label1.local1

..next  ; label1.local1.next

...loop1  ; label1.local1.next.loop1

...loop2  ; label1.local1.next.loop2

.local2  ; label1.local2

..next  ; label1.local2.next

...loop1  ; label1.local2.next.loop1

Each additional dot refers to the previous local label containing 1 dot less...

Thanks!

[ped7g]

maybe between easy and medium, can't think of any difficult issue with this.

But I don't instantly like this, feels way too fancy/abundant.

But let's keep it open here and see if there's more people with opinion on it, maybe showing it more favor than me (at least I'm not hard against it, it's not mandatory to use it if it would be added).

[fmafma]

Thanks!

It could be useful to organize defines:

OBJ
.POS
..X     EQU 100
..Y     EQU 150
.DIR
..X     EQU 1
..Y     EQU 2
.COLOR
..FOR   EQU WHITE
..BACK  EQU BLACK

        LD   H,OBJ.POS.X
        LD   L,OBJ.POS.Y
        LD   D,OBJ.DIR.X
        LD   E,OBJ.DIR.Y
        LD   B,OBJ.COLOR.FOR
        LD   C,OBJ.COLOR.BACK
        ; Do something

or in sub-routines:

mySubRoutine
        ; Some code
.part1
        ; Some code
..loop
        JR   NZ,.next
        DJNZ .loop
..next
        ; Some code

.part2
        ; Some code
..loop
        JR   NZ,.next
        DJNZ .loop
..next
        ; Some code

[AuraEvey]

Even though I'm all for organising defines, there is a certain contradiction here. These are no longer "local" labels, but rather conceptual non-memory related structures.

Additionally, I find the consecutive dots confusing and in the subroutine example I'm surprised to see:

djnz .loop

instead of

djnz ..loop

There is a logic gap there that requires the user to look at the labels and figure out which loop each instruction is jumping to. What happens if the subroutine is long? Do we need to read up and down for pages, to figure out what is what and where we are going to jump to?

In my opinion, the subroutine example is incorrect and doesn't add anything that couldn't be achieved by simply using different local label names. The entire idea of a local label is to make sure it stays local to a module. I don't believe the code will be more readable if we are able to use multiple levels of local labels. As I said, in the case of large routines this will be a headache to read.

Regarding the define example, I would prefer something explicit like defStruct. For exampe:

defStruct OBJ
    defItem POS
        X EQU 100
        Y EQU 150
    defItemEnd
    defItem DIR
        X EQU 1
        Y EQU 2
    defItemEnd
    defItem COLOR
        FOR EQU WHITE
        BACK  EQU BLACK
    defItemEnd
defStructEnd

Obviously you could just use curly braces to indicate the start and end of all sections instead of using keywords like defItemEnd (which would make it more readable than my example is).

I am a strong proponent of simplicity in both tools and code. The local labels have a specific reason to exist and are as simple as it comes. Making them do a secondary or even a tertiary job, makes things complicated and the future maintenance costly.

[fmafma]

I agree that the use case in the sub-routine is not very good¹, but I'm not a big fan to introduce a new paradgim (with 2 more keywords!) to implement the define hierarchy; for this use case, I think nested labels are very easy to use and understand.

For the maintenance of SJASM+, on the other hand, I can't say. Hence my initial question ;o) Maybe something to think about for branch 2.x?

Best,

¹ even if jumps in a long code is always complicated to read, nested labels or not; long routines are never a good idea, whatever language you use.

[fmafma]

In fact, I would definitly have great use of nested labels in sub-routines!

Even in a reasonnable size one, I often have several sub-sections, with their own loops/relative jumps.
Without nested labels, I need to increment the names (loop1, loop2... or next1, next2...), and have them renamed when adding/removing code.
With nested labels, it would be much easier.