Flow-control structures: Difference between revisions

Line 1,511:

=={{header|Phix}}==

===goto===

In 0.8.4+ Phix finally has a goto statement:

There is no hll goto statement in Phix. However in the very rare cases a goto is genuinely needed in hll code, the following

construct(s) may be used:

procedure p()

goto :but_print

puts(1,"This will not be printed...\n")

::but_print

puts(1,"...but this will\n")

end procedure

p()

⚫

Imposing a self-policed rule that all jumps must be forward (or equivalently all backward, but never mixed) is recommended.

Phix imposes the following limitations on the use of goto statements:

A goto statement must be in the same function as the label it is referring.

The goto statement is not supported in top level code, outside of a routine definition.

There are no computed, assigned, or multiple target forms of the goto statement.

Goto may not be used and labels may not be defined anywhere inside a try/catch statement.

Jumping over variable initialisation will, naturally, leave the variable unassigned.

A goto can optionally refer to label or :label - they mean the same thing.

(Technically the colon-less variant is shorthand for the formal with-colon label reference.)

A label, which adheres to the usual identifier rules, is defined by preceding it with a double colon.

Note that a goto statement, or inline assembly (a goto statement is implemented using fragments of auto-generated inline assembly) will cause the compiler to abandon certain optimisation efforts, in particular type inferencing and constant propagation, which can result in a larger and slower program.

Previous versions had no hll goto statement, however the folowing work around was (and still is) available:

<lang Phix>#ilASM{ jmp :label }

...

Line 1,537:

Line 1,561:

local labels are declared with "::" but referenced with ":".

Making "goto" somewhat more difficult to type in this manner ensures that

it is far less likely to be abused, and discourages newbie programmers

from adopting it as a weapon of choice, as usually(/always) happens with

a hll goto.

</it was claimed>

===exit===

causes immediate termination of the immediately surrounding for or while loop, with control passing to the first statement after the loop, eg:

<lang Phix>~~for i=1 to 100 do~~

for i=1 to 100 do

if a[i]=x then

if a[i]=x then

location = i

location = i

exit

exit

end if

end if

⚫

~~end for~~</lang>

end for

⚫

===continue===

~~causes~~ the next interation of the immediately surrounding loop to begin immediately, with any condition evaluated normally, eg:

Causes the next interation of the immediately surrounding loop to begin immediately, with any condition evaluated normally. The following two loops behave identically:

<lang Phix>~~for i=1 to 100 do~~

for i=1 to 100 do

if a[i]=0 then continue end if

if a[i]=0 then continue end if

...

...

⚫

~~end for~~</lang>

end for

for i=1 to 100 do

if a[i]!=0 then

...

end if

end for

===return===

~~exits~~ the current routine. Needs a value to return if used inside a function or type.

Exits the current routine. Needs a value to return if used inside a function or type.

===break===

~~terminate~~ a switch statement. fallthrough is the opposite, overriding an implicit break between cases.

Terminate a switch statement. fallthrough is the opposite, overriding an implicit break between cases.

===abort===

===abort, crash, throw===

~~terminate~~ the entire application immediately.

Terminate the entire application immediately, unless caught by a containing try/catch statement.

Technically it is possible to use these to effect control flow, albeit in a grossly inefficient manner.

===tasks and threads===