GoTo Documentation

General
1

I have literally not used GoTo for several decades, but I decided to look a Xojo’s documentation of it . There it says:

[code]GOTO label

Part Type Description
label String Label to which to jump
[/code]

I said to myself "Hmmm well a label is usually its own thing … but if the label is actually a string, GOTO might actually be useful In Xojo… It might be possible to write code like :

[code]MethodPerformAction(ActionToPerform as String)
Goto ActionToPerform

A:
MsgBox “A”
Return

B:
MsgBox “B”
Return

C:
MsgBox “C”
End Method[/code]

Which in theory (if the complier was smart enough), could be a bit more efficient that using a long Select Case statement with say an Enum, but be just as readable…

But of course that does not compile… So maybe the docs should not call the label as String? Maybe just Identifier or some such?

2

Yeah Label isnt a “string”
Its an identifier followed by a “:”
And all of this is resolved at compile time - not runtime
So no you cannot do what you’re thinking - at least not that way :stuck_out_tongue:
A jump table would work though but would be very tailored to the situation

Basically a jump table might be an array of delegates that all have a common signature
Then the index is perhaps the ASC of a single character (handy in various kinds of parsers) and you have a table of 127 delegates (one for every ASCII character)
And you just invoke whatever delegate is stored at that index (or maybe you have some that have no delegate so you need to check if the entry is nil)
This is how to write code that does not use an if to run conditional code :stuck_out_tongue:

Or you use a Dictionary and the dictionary has keys (like you wanted above) and a delegate stored as the value.

Lots of options

3

its wrong
its been wrong like this forever :frowning:
literally the very first import into the wiki had it this way

<https://xojo.com/issue/56024>

4

When you said Delegate, my mind said, “yep, but Select Case works fine for me” :stuck_out_tongue:

5

this is the “how to not use if or select case and make it stunningly fast”

its one of those “interview questions”

  1. write some code that only uses IF to execute the correct code for any given single character string
  2. same but use select case
  3. same but no if or select case is allowed

most get 1 and 2 - a few get #3
#1 and #2 just enumerate ever option
#3 is a jump table

6

… so, LABEL: should be a … ?

7

IDENTIFIER followed by a : followed by an END OF LINE

an identifier is [a-zA-Z][a-zA-Z0-9_ utf8 character]*
-basically no puntuation and some others following the first ascii character

same rules as for the name of a method, property, constant etc

the IDE SHOULD reject names for user identifiers that start with a _ but I have seen spots where that is not the case

8

[quote=441242:@Norman Palardy]Yeah Label isnt a “string”
Its an identifier followed by a “:”
And all of this is resolved at compile time - not runtime
So no you cannot do what you’re thinking - at least not that way :stuck_out_tongue:
A jump table would work though but would be very tailored to the situation

Basically a jump table might be an array of delegates that all have a common signature
Then the index is perhaps the ASC of a single character (handy in various kinds of parsers) and you have a table of 127 delegates (one for every ASCII character)
[/quote]

Norm,
I never really expected GoTo work like that and I knew the other options solutions … It’s just that this one (if it had been doable) would have been the easiest/least amount of work!

I was considering using an array of delegates with an enum that could be directly cast to the index (very efficient) … But well that is just a lot more work to set up (creating separate methods etc) , than I am willing to do! (I am lazy!!! :wink: )

Select Case is probably the most practical option, as each “method” would only be 1 to maybe 5 lines of code

9

The proper Lang Ref entry for GOTO (or GOSUB)

10

I seem to remember a conversation from about 6 years ago (when Realbasic became Xojo) that there was a case for removing Goto or not. Most of the same players here too :slight_smile:

11

Yeah dont
There are valid use cases for it - but they are quite rare
see comments on https://www.bkeeneybriefs.com/2019/05/dont-use-goto/

12

[quote=441242:@Norman Palardy]Yeah Label isnt a “string”
Its an identifier followed by a “:”
And all of this is resolved at compile time - not runtime
So no you cannot do what you’re thinking - at least not that way :stuck_out_tongue:
A jump table would work though but would be very tailored to the situation

Basically a jump table might be an array of delegates that all have a common signature
[/quote]

That is Lot of setup/complication (and more overhead) than is warranted for many cases (like the one I am dealing with! :wink: )

What I would really like is a “computed” GotTo (IIRC Fortran had something like that)… That is what I meant by the compiler being smart… essentially creating a jump table for use within the method…

Internally the compiler could create the following:

Array Labels() As String or Enums ' i doubt there would ever be so many that a dictionary would be significantly faster
Array LabelAddress() As Uint64

      JumpTo  LabelAddress(Labels.Indexof(LabelStringOrEnum))

Or If it was implemented as Enums only who’s integer value directly corresponded to the index of the address internally that could simplify to:

JumpTo LabelAdress( Ctype(theEnum,Integer) )

Either should be blazingly fast compared to Select Case… Also probably faster than using an array of delegates, as it avoids any overhead associated with using delegates but also potentially that of method calls…

With a Computed Goto solution one has the option of using methods when appropriate, or when an option takes only a few lines of code do it within that method to avoid that overheard…

And it would CERTAINLY be a lot less work/time to configure than the delegate solution and be more flexible … and RAD is a Xojo selling point!

It would about as much work on our end as setting up as Select Case, but a lot better performance.

That is why I thought maybe a Goto that could take a variable as the label might be a good thing.

Xojo has rep for being slow at somethings (without resorting to arcane solutions or plugins)…

But features like a the above (they would not have to call it A Computed Goto… maybe JumpToCase to avoid stigma) and being able to Freeze a MemoryBlock (and have the framework methods work directly with that instead of converting to string) could help eliminate that perception without making huge API changes that would break code.

This is lower level stuff than typical for Xojo, but done that way not THAT low, and still with reasonable safety.

Just some thoughts about what can help make Xojo be seen as a more “powerful” language (and help me do what I want to :wink: )

(BTW I see the docs have been fixed on GoTo)

-karen

13

There is no gosub in Xojo.

14

Effectively you just described select case

15

While it has similarities for sure, it has significant and important differences that matter for execution speed. See the other thread.

  • karen
16

its select case using different words

17

You can consider it a special case of Select Case if you want, but I think that optimizing the execution speed of that use (which I suspect is a pretty common usage) is worth it.

If you don’t, we will just have to agree to disagree… It won’t be the first time over the years! :wink:

  • karen
18

use select case with simple cases (numeric types) and it will be decent

dim i as integer
select  case i
 case 1
 case 2
 case 3
/// etc
end select

as these are about as simple a as there is - its done in hardware and requires not additional code like a complex case would
will it be as fas as the jump table I talked about ?
no - because it has to do at least one comparison (possibly more)
but then so would yours

the jump table I talked about uses zero comparisons which is what makes it faster

19

I worked with the Eliza code from 1986 to create a small app.
https://apps.apple.com/us/app/eliza/id1222391512?mt=12

The author uses a bunch of structures like

10 If this goto 20 15 do something 20 do something else

When I started QuickBasic, I used gosub extensively, for small subroutines.

Early VB still supported it.

VB. Net dropped it.

It makes sense for Xojo not to support it. Today it is much faster, and better, to create a small method.