Goto label inside a select case block?

[Brian Alvarez]

This code:

Code: [Select]

goto NOLabel
select case 1
    case 2
        NOLabel:       
end select
Or code like this:

Code: [Select]

goto NOLabel
if 1 then
   NOLabel:       
end if
Produces this:

Code: [Select]

Linker found unidentified names:
1102 nolabel "main source
Is this a known limitation?

 I know PHP does not allow to jump into blocks of code... and i never got why... as long as all the variables are initialized it should not be an issue...

[Charles Pegge]

Hi Brian,

in o2, labels and other symbols defined inside a block are not visible from the outside. It's good for modularity though occasionally inconvenient.

[Brian Alvarez]

Can something be done to overcome this? A lot of code relies on being able to do so...

[Charles Pegge]

Block-scope is a fundamental feature of o2 at all levels.

Jumping into the middle of a block, indicates the code needs to be restructured. It cannot be safely maintained.

[Brian Alvarez]

I tend to have a bittersweet opinion regarding that, but that is not the point. Since i need to be able to allow this, for all the existing code that uses this "dangerous" structuration, i would like to find a way.

Can i still use low level statements to jump to labels?

 I mean... Since PluriBASIC knows the label is there... is there a way to call... lets say:

Code: [Select]

jmp @nolabel
 Without compile-time errors? Otherwise i will have to re-write my own if/then select/end select /do/loop blocks using goto myself...

[Aurel]

Hey Brian

hmm ..i really don't know any basic dialect in which you can jump inside CASE statement 
don't get me wrong ..but that looks like suicide.

[Brian Alvarez]

I thought everyone here knew PowerBASIC...

[Arnold]

Somehow these constructs look strange to me. It is almost like e.g. jumping into a while .. wend loop:

goto thislabel

string s
while 1
thislabel:
  s = "Hello"
  exit while
wend
print s " World"


I am happy that Oxygen will prevent nonsense like this:
...
goto lbl1
    select case wMsg
      case WM_CREATE
...
      case WM_DESTROY
lbl1:
      PostQuitMessage 0
...

To my surprise this is allowed:
...
    select wMsg
goto lbl1       
      case WM_CREATE
...
      case WM_DESTROY
lbl1:
print "here"         
      PostQuitMessage 0
...

[Brian Alvarez]

Arnold, consider this situation:

Code: [Select]

SELECT CASE Situation
    CASE A, B, C
        ' Do something that i want to do here, but not in D, E and F.

        GOTO DoTheRestOfTheTasks
       
    CASE D, E, F
        ' Do something that i want to do here, but not in A, B or C.
       
        DoTheRestOfTheTasks:       
        ' Do the tasks that apply to All the cases.
       
END SELECT
If you are worried about the CPU registers getting messed up or not correctly initialized, then remember
that in some cases (not all) MACROS can also do stuff like that.

 The above code is more powerful and flexible than what other languages do. Have you seen
Swift's (relatively new programming language) fallthrough? Or... the automatic fallthrough in C++'s SWITCH
statement?

 For some, those can sound crazy, but are very powerful and once you get the hang of them, can become
easier to debug. Consider the above example, I could also do it like this:

Code: [Select]

SELECT CASE Situation
    CASE A, B, C
        ' Do something that i want to do here, but not in D, E and F.

        CALL DoGlobalTasks(A, LIST, OF, ALL, THE, PARAMETERS, THAT, I, NEED, TO, USE, TO, COMPLETE, THE, GLOBAL, TASKS)  ' Do the rest of the tasks...
       
    CASE D, E, F
        ' Do something that i want to do here, but not in A, B or C.

        CALL DoGlobalTasks(A, LIST, OF, ALL, THE, PARAMETERS, THAT, I, NEED, TO, USE, TO, COMPLETE, THE, GLOBAL, TASKS)  ' Do the rest of the tasks...
       
END SELECT
 Better, some would say, but for me, unnecessarily adding complex parameters in a language that was designed to be simpler and quicker to work with is an undesired  hassle.

 Sometimes i do that out of need, but when there are statements like this...

Code: [Select]

    CALL moduleParts(SD(), 10, ISTRUE(MOD_DATA(SD(oIndex).Index).DataType), 0, MODULE_DATATYPE, VAR_DATA(SD(oIndex).Index).Flags, UDT_DATA(SD(oIndex).Index).Flags, isConDes, Comp(SD(oIndex).Index).Tags, Memory.Globals.Sect(SD(oIndex).managed).Pointer, "")
Trust me... i rater use a small GOSUB than stating the parameters i need in each case, because, this last one, is much harder to mantain or debug than a single GOTO/GOSUB.

[Arnold]

Hi Brian,

comparing with the Situations cases example above, this would make more sense to me and it works also:

Code: [Select]

$ filename "TestLabel.exe"

'uses rtl32
'uses rtl64

FUNCTION PBMAIN() AS LONG

LOCAL ti AS LONG
'ti=88888
select CASE TI
   case 0
     GOTO thislabel

   CASE 88888
print "here"
    CASE ELSE
      thislabel:
        print " it works"

END switch

END FUNCTION

PBMAIN()


Would this appoach be applicable?

[Brian Alvarez]

I am happy that Oxygen will prevent nonsense like this:

Code: [Select]

goto lbl1
    select case wMsg
      case WM_CREATE
      case WM_DESTROY
lbl1:
      PostQuitMessage 0

 Hehehe, to me, that looks like a deliberate attempt to make GOTO look dangerous.
That is an accident that can also happen without jumping into a SELECT/END SELECT block.
Sometimes a typo is all what is needed, and even then, nothing that a recompilation cannot
fix. Not the end of the world.

 Demonizing a GOTO with freedom because you can jump to a wrong place, is like demonizing
a knife because you could cut yourself with it.

I am sure you dont cut onions with a spoon.

[Charles Pegge]

Referring to Brian's first example:

Code: [Select]

SELECT CASE Situation
    CASE A, B, C
        ' Do something that i want to do here, but not in D, E and F.

        GOTO DoTheRestOfTheTasks
       
    CASE D, E, F
        ' Do something that i want to do here, but not in A, B or C.
       
        DoTheRestOfTheTasks:       
        ' Do the tasks that apply to All the cases.
       
END SELECT

The simplest solution might be:

Code: [Select]

SELECT CASE Situation
    CASE A, B, C
        ' Do something that i want to do here, but not in D, E and F.
       
    CASE D, E, F
        ' Do something that i want to do here, but not in A, B or C.
    CASE ELSE
       GOTO NSEL   
END SELECT
'Do the tasks that apply to All the cases.
NSEL:


[Brian Alvarez]

Would this appoach be applicable?

 Hello Arnold, yes, of course. But im not trying to acomplish anything with that code except
explaining why is useful to jump from one case to another.

 What i am trying to do is to be able to compile a lot of existing code, some of which contains
GOTO/GOSUB statements that jump into structures with no restrictions.

 Is not like i have an option.

[Brian Alvarez]

 I already removed the ability to jump into structures from PluriBASIC. It now generates a compile-time error.

If there is a need, i might end up creating my own structures. Using goto. 

Code: [Select]

' DO
InitialDo00001:


'LOOP UNTIL Done
IF Done THEN GOTO EXITDo0001
GOTO  InitialDo00001
EXITDo0001:


[Charles Pegge]

As another solution, I found flags to be very useful when dealing with complex logic, especially in the o2 source code: The logic is easier to read.

Code: [Select]

INT t 'action flag
SELECT CASE Situation
    CASE A, B, C
        ' Do something that i want to do here, but not in D, E and F.
        t=1
    CASE D, E, F
        ' Do something that i want to do here, but not in A, B or C.
        t=1
END SELECT
IF t
'Do the tasks that apply to All the cases.
ENDIF