3 ms·
Loops are very easy to debug in R. When they break and they're not inside a function, your REPL state is set to exactly what the environment was before the loop
by civilized 4y ago
Loops are very easy to debug in R. When they break and they're not inside a function, your REPL state is set to exactly what the environment was before the loop broke.
- p10_user 4y agoCan’t you do the same thing by dropping a browser() into a function you are applying to each element in a list?
- civilized 4y agoIt's not as convenient because now you have to rerun the code and get in and out of a debugging environment (which can be slow). I think FP is good for more concisely expressing simple stuff that's unlikely to break. Don't really believe in using it as a complete replacement for loops.
- p10_user 4y agoHow about a conditional breakpoint? Though this doesn’t solve the “issue” of rerunning through the whole list. Or - once you’ve found what element in your list is causing the issue- extract it and feed it to your function with your debugger on. Admittedly I have often had a more challenging time fixing FP code than if I had used a for loop. This might be because I am not as familiar/comfortable with FP than procedural flow. There has to be a for loop eventually. But crawling through a for loop within a procedure can also be painful if there are many different case scenarios. You could counter that good code wouldn’t suffer such a problem, but if the code was good it might not have been broken!