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