[comp.lang.misc] Breaking loops

flee@shire.cs.psu.edu (Felix Lee) (02/20/90)

Scott MacHaffie <machaffi@cs.washington.edu> wrote:
>Unconditional loops have a serious problem: you have to read all of the
>code inside the loop to find out when (or if) it terminates.

Well, not if you undent the terminating conditions properly:
	loop
	    do_stuff();
	break cleanup() when (done);
	    do_more_stuff();
	end loop;

Unfortunately this isn't convenient in most languages.  C doesn't have
an inverted if statement, so undenting is confusing:
	for (;;) {
	    do_stuff();
	if (done) { cleanup(); break; }
	    do_more_stuff();
	}
The last brace looks like it closes the if statement.  I usually just
mark break statements with a /*BREAK*/ off to the right somewhere.

Ada has "EXIT loop WHEN condition;" which you can undent, but doesn't
provide for a cleanup clause.  But you often don't need one anyway.
--
Felix Lee	flee@shire.cs.psu.edu	*!psuvax1!flee

kers@hplb.hpl.hp.com (Chris Dollin) (02/23/90)

Jim Giles writes:

   I)   Recursive data types.
   ...
	   (Functional languages usually don't allow cyclic data structures.)

Any such functional languages are brain-dead. The non-strict (often sloppily
[and I'm no exception!] referred to as "lazy") languages permit circular
structures as in eg

    let rec ones = cons( 1, ones )

[The syntax, of course, varies]. The strict languages (such as ML and Scheme,
if we permit them to enjoy the adjective "functional") contain assignments
which permits the construction of circular structures.

Regards, "But I program in Pop-11 whenever I can" Kers.

jlg@lambda.UUCP (Jim Giles) (02/24/90)

From article <KERS.90Feb23100957@cdollin.hpl.hp.com>, by kers@hplb.hpl.hp.com (Chris Dollin):
> Jim Giles writes:
>    I)   Recursive data types.
> 	   (Functional languages usually don't allow cyclic data structures.)
> Any such functional languages are brain-dead. The non-strict (often sloppily
> [and I'm no exception!] referred to as "lazy") languages permit circular
> structures as in eg
>     let rec ones = cons( 1, ones )

But, this is _not_ a circular list - it is an infinite one.  Semantically,
this is _not_ a list with one element that cycles, it is an infinite list
of ones.  Now ,it may be _implemented_ as a circular list, but that's
not what it 'is' (just like 'structured' control flow construstc are
_implemented_ with GOTOs, but that's not what they 'are').  The distinction
permits the language environment more freedom in the implementation.  Some
functional languages on multiprocessor/multimemory machines will actually
implement the list itself.  Because evaluation of anything is demand driven,
it won't actually generate any elements until they're needed (keeping the
generation rule separate from the list).  The reason that it generates
the list is that the elements of the list may be spread among the processors.
If a processor had to go to _the_ cyclic list for each element of 'ones',
it would waste a lot of inter-processor bandwidth.  Instead, if a processor
needs (say) the third element of 'ones', it just goes to the _nearest_
processor which already has a copy of that element (which is only sometimes
clear back to the original definition).  If you think about it, this makes
sense - the definition of (say) factorial is also a recursive one.  If
each processor had to calculate the elements of factorial from scratch
when some neighboring processor had already calculated the element you
need, it would be a real waste of time.  This is what demand driven
processing is all about.

> [The syntax, of course, varies]. The strict languages (such as ML and Scheme,
> if we permit them to enjoy the adjective "functional") contain assignments
> which permits the construction of circular structures.

I don't think I will permit such languages to enjoy the adjective
"functional".  If they contain assignments, they are, most certainly,
NOT functional.

J. Giles