Use reductions to create lazy sequences #2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
All of the algorithms use
lazy-seq
andcons
to build a lazy sequence of steps in carving out the maze. That process is a little bit fiddly; at least, it's hard for me to remember what should go where when I'm writing something like that from scratch.But the
reductions
function manages all of that for you. It's just likereduce
, but produces a lazy sequence of all of the intermediate values instead of just the final value. I wasn't aware ofreductions
when I originally wrote all of this code.This is a draft because so far I've only converted
binary-tree-seq
, as it was the easiest. The others have additional intermediate state they pass from step to step; to work withreductions
they will have to move that extra state to a field within the grid. (Alternatively, the state value for the reduction could be a tuple of[grid other-state]
and the code that uses the lazy seq fromreductions
would have to know to mapfirst
over the sequence before using it. However, I think adding the extra algorithm-specific state to the grid is the better approach; it's part of Clojure's philosophy that maps should have documented required or optional fields for public consumption, but it's perfectly acceptable for code to add extra fields if needed for their own purposes, and consumers should just be prepared to accept and ignore fields that they don't know about.)There's an additional change that I could also implement while doing this. All of the algorithms come with
alg-seq
andalg-seq*
function pairs. The unaryalg-seq
function just prepares the grid and then kicks off the process by callingalg-seq*
, which always takes more than one argument. I suspect I did it that way because thealg-seq
functions are intended to be called from outside this namespace, but thealg-seq*
functions should only be called from their correspondingalg-seq
function. But I think instead it would make more sense to just have thealg-seq
functions support multiple arities, and have their docstrings only document the unary version. Then the unary version would prepare the grid and callreductions
to use the binary version.