'while/else' (ugh) (was Re: [oclug] Ruby)

[Francis J. A. Pinteric]

On Sat, 28 Jun 2003 02:41:34 +0100
Matthew Wilcox <willy at debian.org> wrote:

> On Fri, Jun 27, 2003 at 06:45:36PM -0400, Francis J. A. Pinteric
> wrote:
> > On Fri, 27 Jun 2003 21:37:04 +0100
> > Matthew Wilcox <willy at debian.org> wrote:
> > >
> > > [code snipped for brevity]
> > >
> >
> > This would have a high probability of crashing when you tried to
> > free`ptr' if`condition' was false(ie. zero) at the start.
> 
> ok, smartypants:
> 
> if (!condition)
> 	return;
> 
> ptr = malloc(lots);
> do {
> 	stuff(ptr);
> 	condition--;
> } while (condition);
> free(ptr);
> 

Well, that will work!  However, the point of the `else-while' clause, or
as I'm implementing it, the `finally' clause, this really isn't a good
example.

In your code, you are pre-allocating space that is to be freed later. 
What if you can't do that in advance?  Let's take a real world example. 

You are sitting on the tail end of a data stream from a machine.  This
machine has a number of different states that it can be in and the
data that it transmits depends on the state that it is in. This
machine inexorably passes from one state to the next, barring error
conditions.  As each state progresses, you need to report on
the progress and/or trigger other things to happen.  On successful
completion of all stages of the process that this machine is reporting
on, the machine enters a completion state with an appropriate message
that will trigger another machine.  In the case of an error, it
transmits and error code and goes into an error state where it awaits a
clearance code to reset it back to an initial state which starts the
whole process all over again. Any other command to the machine results
in an error code, which means that the machine is essentially locked up.
In either case, the machine will not process anything further until
it's `end' or `error' state is cleared. Your code is controlling this
machine.

How would you write code to handle this? Before you object, there are a
lot of real world machines that operate exactly this way.  And I've
provided all the information you'll need to solve the puzzle.

Here's proposed pseudo-Vega code:

<code>
initialize_the_process
while !process_reports_completion:
	if error:
		do_error_processing
		break
	end
	do_state_specific_processing
finally
	do_process_completion_stuff
end
reset_machine_back_to_initial_state
</code>

Obviously, the `break' statement does not trigger the `finally'
statement.  In pseudo-C, it might look something like this:

<code>
initialize_the_process;
while( !process_reports_completion ) {
	if ( error ) {
		do_error_processing;
		break;
	}
	do_state_specific_processing;
}
if( I_find_out_that_the_process_completed ) {
	do_process_completion_stuff;
}
reset_machine_back_to_initial_state;
</code>

Here we see that the pseudo-C code requires an additional conditional
test to discover if it had arrived at it's destination as a result of
proper completion.  Some may move the error processing via a `goto' and
depending on the nature of the code construction, might be necessary. 
However, properly constructed C code requires zero `gotos'.

Currently, there is no `goto' in Vega.

>>>--fja->





-- 
Fashion is for people who have no style.

There are three crimes which deserves the death penalty:
conformity, political correctness, and smoking.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://tux.oclug.on.ca/pipermail/oclug/attachments/20030627/89fed75b/attachment.bin