Hi Steve,
Thanks for your comments, I appreciate any input.
> Do you think the software in the Apple iPod is "simple"? Or Microsoft
No, that's much more complicated that what I am doing.
But the iPod probably (?) doesn't get new algorithms based on a
specification discussed with non-programmers once a month.
I didn't explain enough of what I am doing. This is a fairly complex
application that has been running for a few years now,
I am just trying to improve it. The code runs a big
test machine, that runs >100000 individual tests in one run on
something like semiconductor chips.
The specification of these tests is already very complex, it has the
form of the nested loops,
for all these configurations try these steps, if they fail try them
again n times, if it still doesn't work give up
this configuration, if it works continue on to the next steps etc.
That's the form the specification is in, and it makes sense and is
very readable.
In pseudocode it looks like this, I am using @ to give loops a name:
@loop1
for c in configurations:
@loop2
while not_done:
@loop3
while step1_did_not_work:
@loop4
for substeps in step1 # loop 4a
if hopeless(): continue loop1 # run next configuration
if substepsFailed(): restart loop4 # try again
if substepsWorked(): break loop3 # go on to next
steps, like loop4
That format is fine, everyone involved can understand it, even the
people in charge. I'd like to make this executable without
changing too much of the form. It would be possible to do this as a
FSM, but then you'd loose the line to line correspondence with the
specification, and of course some errors always creep in.
> non-CS people to be hacking the source code, they only interact with the
This is a research setting, so the person running the machine will
have to change the source from time to time if
he gets a new specification. The specifications are far to complex to
be entered into a user interface because of all the loops.
> the code by splitting it into functions appropriately, instead of the
> spaghetti code you have (apparently) written with jumps all over the place.
I wouldn't call the example above spaghetti code in the sense of old
Fortran or Basic full of gotos.
In a language that can break out of nested loops this is highly
structured code.
I am not jumping forward to labels, not jumping into functions, not
using jumps to replace loops etc.
It is like the Fortran example (just to show the syntax, has an
infinite loop), everyone can understand that right away, even
non Fortran people:
10 loop1: do I=1,3
loop2: do J=1,4
print *,I,J
goto 10 ! redo loop1
cycle loop1
exit loop1
enddo loop2
enddo loop1
There is no wild jumping her. The only problem is that Fortran does
not allow to restart a loop, so instead of restart loop1 you have to
do a goto 10. Otherwise you could do entirely without gotos (like in
Ruby with the redo, which is of course much much better)
> To take the most obvious, simple example: any time you have a loop that you
> might want to redo, the right solution is to put the loop inside a
> function, and then "redo the loop" becomes "call the function again".
Doesn't work, because it can only redo one level, to break out of the
next loop, I'd need exceptions anyway.
And having all of these exceptions as gotos doesn't make it more
readable.
Replacing loop4 by a function makes it possible to replace the restart
loop4 by a return, but then I still need an exception to
continue loop1 and one to break out of loop4 to indicate that we can
go on to the next step.
> I suppose that, just possibly, your application really would benefit from
> named labels to jump to. But if so, you've stumbled across something rarer
> than iridium.
Don't think so. I am doing that all of the time in other languages,
and I am convinced the named loops (not raw labels+gotos, which are
just a necessary evil) are beautiful and clean things.
They have a lot of symmetry, break is always break, not sometimes
break, sometimes return and sometimes raise breakSomeLoopExcept().
Rewriting the simple Fortran example above in Python would be much,
much uglier and more difficult to comprehend.
You always call break and continue with a label, searching for that
label will tell you right away which loop the break breaks.
I am always doing that, even if there is only one loop. break and
continue (without label) are IMO (please no flame war about that)
worse than goto, at least the goto tells you where it goes, with break/
continue you always have to scan the surroundings to find the right
loop.
I know I am not the only one who is trying to solve that problem, I
was hoping someone has come up with a hack to solve it, like this goto
Chis has come up with. I have to play with that a bit.
Dan
--
http://mail.python.org/mailman/listinfo/python-list
