RPL equivalents to BREAK, CYCLE, EXIT, etc.?

[DavidM]

(06-08-2014 01:57 PM)Thomas Radtke Wrote:  Hard to imagine that especially RPL fans don't miss BREAK etc. as any workaround consumes more code when more compact code should be disireable on a device with very limited display.

Whether or not you need to "workaround" not having BREAK is a stylistic issue. If you don't design code that depends on its existence to begin with, then you don't see it as a workaround at all.

Regarding the display, I might feel differently if I actually wrote a lot of code directly on my 50g. I don't. All of my RPL/SysRPL/Saturn coding is done on a laptop using an emulator and transferred over, so display limitations aren't usually an issue for me. I realize that lots of people still do all their coding directly on their calculators, though.

(06-08-2014 01:57 PM)Thomas Radtke Wrote:  However, it remains to show that the omission of BREAK (we're not talking about GOTOs) makes code less readable or maintainable.

This is a very subjective issue. Yes, I agree that BREAK is not in the same class as GOTO. In some situations, BREAK isn't very far removed from something like CASE when it comes to reading and maintenance.

Where it can be problematic (IMHO), is when people start using it in the context of exception handling. For example, using a definite loop that really should have been set up as an indefinite loop from the beginning. If you catch yourself adding a BREAK while debugging a loop because of an unforeseen situation arising, that's a good time to ask whether you designed the loop properly from the start. Similarly, adding a BREAK to handle an occasional outlying condition is probably a good sign that error trapping or pre-checking the parameters is a more appropriate model.

Whether using these alternatives makes code more readable/maintainable is a purely subjective issue. In my opinion, it does. I don't expect everyone to agree with me, but this one of those times when I actually do agree with the doctrine of my formal training.