local goto

[StefanKarpinski]

Basically a jmp instruction within a function, much like C's local goto. Requires two pieces of syntax:

1. labels
2. goto statements

One issue to keep in mind is that goto might get used anywhere return does, including this:

x = a < b ? -1 :
    a > b ? +1 : goto equal

Also: is there any way we can hack this in with minimal changes using the existing macro syntax?

[StefanKarpinski]

See http://kernel.org/doc/Documentation/CodingStyle, Chapter 7 for rationale of this kind of goto. Local gotos are also, in my experience, the only sane way to handle interactive input with error handling where you might need to unwind the input back to various input stages.

[Borgvall]

A goto in an assignment!? What is supposed to happen, if x is used afterwards?

The Linux CodingStyle Chapter 7 has a very specialized use case for goto ("centralized exiting of functions"). It might be good to have a language feature rather than relying on convention. Maybe a "prereturn" keyword:

function foobar(...)
    # allocate memory
    ...
    # do something
    ...
    if (isGood(foo)) then return foo else return bar

prereturn
    # clean up my mess
    ...
end

Note that this is only needed because of the "stop the function execution" characteristic of return. For most other use cases a "local function/method" would be a less clumsy way. Proper error handling should be done by some sort of "try/catch". In short gotos even local ones propably generate more problems then it solves.

[StefanKarpinski]

If x were used after that, I would say the same thing would happen as if x simply hadn't been assigned: you get an "x not defined" error. The kernel-style single exit point is only one particular use case for a local goto; there are others. Handling interactive input with error handling with the option of unwinding multiple inputs, for example:

preA:
  A = get_input_A()
  if bad(A); goto preA; end
preB:
  B = get_input_B()
  if bad(B); goto preB; end
  if bad(A,B); goto preA; end
preC:
  C = get_input_C()
  if bad(C); goto preC; end
  if bad(A,B,C); goto preA; end

Something like that. This isn't a contrived hypothetical situation; I've written code like this many times. Doing it with if/then is a complete nightmare.

I'm also not sure what problems goto causes when confined to a single method body. Sure, you can write insane, incomprehensible code with goto, but you can do that without goto just as easily. You can also use goto in a variety of perfectly reasonable ways. Moreover it's very efficient and easy to implement, so why not have it for those cases where it's appropriate?

[Borgvall]

That is a typical nested "do{A=getA()}while(bad(A))" loop:

do
{
  do
  {
    do{A=getA()}while(bad(A))
    do{B=getB()}while(bad(B))
  }while(bad(A,B))
    do{C=getC()}while(bad(C))
}while(bad(A,B,C))

However it is not my intention to discuss more examples of that kind. I know one can express any control structure with gotos. In a good designed it should rarely be needed or useful. For most sane things such language contains a "matching" control structure (actually Julia lacks do-while loops).

Update: misses -> lacks; code indentation;

[vtjnash]

I've always thought that return makes a nice non-local control construct, with the added benefit that functions stay shorter and more composable. (although the net length of code might be a bit longer)

Nested loops on the stack:

checked_getA() = while true; A = getA(); if !(badA(A)) return A; end; end
checked_getB() = while true; B = getB(); if !(badB(B)) return B; end; end

function checked_getAB()
    while true
    A = checked_getA()
    B = checked_getB()
    if !(badAB(A,B)); return A,B; end
end

Function cleanup (in most cases this could probably be done with a regular function instead of an anonymous one. to some extent, this is like implementing Python's function decorators):

function foobar(...)
    # allocate memory
    ..
    f = function ()
        # do something
        ...
        if (isGood(foo)) then return foo else return bar
    end
    f()
    # clean up my mess
    ...
end

[pygy]

Local gotos also allow to cleanly emulate tail recursion.

[dcjones]

I'm revisiting a project I had explored earlier to write a Julia backend for the Ragel parser generator, and am finding myself more or less blocked by the lack of goto in Julia. The really fast parsers that Ragel generates assume the host language has gotos, and trying to emulate them with functions and ifs is going to be ugly and slow.

Is there any chance of gotos in 0.3?

Alternately, if llvmcall gets merged, could that conceivably be used to manually emit br instructions to mimic gotos? That would be good enough for me, since this is generated code that need not necessarily be readable.

[Keno]

llvmcall wouldn't allow non-local goto's (where local in this case means within one llvmcall block).

[StefanKarpinski]

I tried just writing macros to emit LabelNode and GotoNode expressions, but that doesn't quite work – the goto part actually does, it's the label that seems to get stripped out in the lowering process.

[dcjones]

I didn't know about LabelNode and GotoNode. After fumbling around I found that the label doesn't get stripped, it's just decremented, so this totally works:

macro label(n)
    LabelNode(eval(n))
end

macro goto(n)
    GotoNode(eval(n) - 1)
end

function infinite_loop()
    @label 1
    @goto 1
    return
end

infinite_loop()

That's totally satisfactory for my purposes.

[vtjnash]

there shouldn't be an eval in the macro. but aside from that, I think this will cause errors in the function lowering code, which does not expect to a label 1 to already exist in the code.

[dcjones]

Ok, I see. So proper goto support does need to be baked in. Yet, if I were feeling dangerous I could just assign my labels backwards from some very large number and they'd be unlikely to collide with julia's which count upwards from 0.

[jakebolewski]

I would love to see the function that made that plan even remotely dangerous...