OpenEuphoria

Re: Breaking the silence

• Posted by Peter Robinson <indorlaw at yahoo.c?m.?u> May 18, 2008
• 623 views

Hi CK

Thanks for reply. I certainly wasn't bothered by anyone's comments, nor by their
actions in advancing Euphoria. In view of the fact that I'm responsible for not
speaking up often, I think it's fair enough that people read some indifference
into that.

But I have been looking at a pattern requiring backward jumps:-

<pre-loop loop-related initialisations>
<pre-loop loop-related statements>
<outer loop start>
        <stuff>
	<inner loop start>
		<error tests>
		<general data check>
		<if start>
			<case 1> -- data passes with flying colours
			<do the business>
			<case 2> -- data not right, but not hopeless
			<modify or prune data>
			<retry> -- goto ????????????
			<case 3> -- different data not right, not hopeless
			<modify or prune data>
			<retry> -- goto ????????????
			<case 4> -- hopeless data
			<return or exit>
		<end if>
	<end inner loop>
<end outer loop>

This is a fairly typical pattern where you might want to back up. The <elements>
could represent statements or groups of statements with or without more loops and
conditionals.

What are the likely re-try points for the retries in this pattern?

I think they could easily be before the pre-loop code, at the start of the outer
loop (either before or after another increment of the loop), after the error
tests or the general data check (since the data has already passed those tests)
or before case 1. I don't think you can say that one of those is overwhelmingly
more likely than another. Nor can you say that a programmer who visualises an
algorithm in this way is off his scone. So, the software tool (the language)
should allow him to map these thoughts to code as directly as possible, without
having to re-frame them or translate them into a different concept.

The present solutions sometimes have problems. If you want to jump to the
pre-initialisation point you could wrap up the pre-code in a procedure, the loop
in a different procedure, then call both (the second recursively) from within the
conditional. But this can be awkward if the two retry cases want different parts
of the precode, or if the excised code, removed from context, is meaningless
(leading to a mysterious procedure dissociated from its context), or if it's all
just too messy.

Jumping within a loop is more complicated because a procedure may need to read
and write substantial local data that has to be passed or globalised. It can also
be harder to hive off code into a procedure because the desired code is in the
midst of nested blocks. For example, the desired routine might include the 'end
if', but not the 'if' (e.g Its natural start is an 'elsif'. In this case, you
have to break up the select-case flow into pieces).

In the example, if you want to jump back to the start of the conditional, you
could simply jump back to the start of the inner loop and redundantly re-run code
that you know will pass because the data has already passed that way. I suspect a
lot of us do that to save trouble.

Flags, or tagging the reformed data, can also be a solution, but it means extra
conditional checks on the majority data to check for a minority cases.

If someone thinks these solutions are good, they should ask themselves why they
want a 'continue' construct, as the same solutions apply to it.

Since the problem involves retreats to different spots, things like 'continue'
can only ever be a partial solution. So after reading all the stuff on
'continue', I have gone over to the 'jumps within blocks' stable.

Cheers
Peter Robinson