moodymudskipper
commented
11 months ago I like the idea but I wonder what this would look like and how it would work.
Functions are common offenders for this situation and I implemented the nested_fun argument for those.
But then what do we do with : expression() or tryCatch() that might nest several of those in a single call?
expression(if(...) ..., if(...) ...)
tryCatch(if(...) ..., error = function(e) if(...) ...)Maybe this would be a more general way, so if we have a several nested inputs they would be called 1*, 1** etc:
Or the other way around
I think I like the latter better because it reads from top to bottom more naturally.
The rule would probably be that whenever control flow is found in an argument the full argument is expanded like this. function definitions might not need special casing.
In few cases when we have deeper nesting of those this might still work, we'd have another box in the old box, and if we use index as in examples above the box indices don't change compared to current situation so this might even be tackled as an ulterior step, so we don't have to dig into the algorithm too much.
Then we'd have to choose if we make it optional, but probably have it work always like this would be fine.
@zkamvar How do these proposals above look ?
zkamvar
I notice that if I have a {withr}-like pattern in my code or use a
suppressfamily function, {flow} cannot disentangle it.I will occasionally have functions that look like this:
When flow encounters the {withr} call, it does not parse the expression. The same is true for calls to
suppressMessages(). As a reproducible example, here is something should produce a simple if/else flow chart:Created on 2023-07-10 with reprex v2.0.2
That being said, I really like {flow}! I'm in the process of onboarding new developers and being able to create these visuals to walk through the logic is super helpful!