Yes, I've used this WHILE lFinished = .f. construct (and 99% of the time still do) where it's *clear* but it is EXACTLY equivalent to EXIT at the point where you set (lFinished=.t.). The 'while not lFinished' doesn't give any more clues that 'while .t.' does as to why the loop would exit (in fact, if you see 'while .t.' you 'know' that there will be an EXIT - you wouldn't know that lFinished wasn't a field in a record that is read in the body of the loop).

IMO++, it's not just programming style - nothing is 'wrong' with either approach unless it obscures what is happening. Forcing all code to a single algorithmic pattern ignores the fact that the code should try mirror the data structure (vide Jackson Structured Programming): elegance isn't just for tailors, it leads to clear, readable, maintainable code. I'll come clean, I very rarely use EXIT and even more rarely use LOOP - I wouldn't be annoyed at it in code I had to maintain though, as long as it were clear what was happening and why it was used.

The best construct I think I have come across, ever, is the VFP scan...endscan (ideally with NO conditions, in a loop with neither EXITS nor LOOPS - purity!). Reading code with this means 'Aha! one record per pass...' straight away.

P.S.
Wish we were discussing this over a beer (or coffee) - it always 'sounds' (and reads) so brutal as text.
Also I've been told about a lecture by someone stating that there should be a COMEFROM as well as GOTO...never found the reference to it though.