OpenEuphoria

Re: Breaking the silence

• Posted by CChris <christian.cuvier at agricultu?e.gou?.fr> May 18, 2008
• 641 views

Peter Robinson wrote:
> 
> 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.

Thanks so much for stating the following:

> 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.
> 

I'd like to see this principle overriding any simplicity based concept in the
design of Euphoria. Quite a few things need to be done to this end.

> 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.
> 

If "retry" makes its way into the language (who knows, after all Æ has it), then
you can do

label "retry-it"
while <whatever> do
    <code to jump back to>
    if do_that_again() then
        retry "retry-it"
    end if
-- stuff
end while

> Cheers
> Peter Robinson

CChris