Open RenaissanceBug opened 5 years ago
If I am understanding things correctly, tree-edge
makes sense only when its argument is not #f
, so the fix we should have is to document it as something like (and/c tree-layout? (not/c #f))
, plus adjusting the contract so the right error message prints.
The reason I say that is that there is no edge to a node that isn't drawn, and that's what #f
is supposed to be. So probably you want this function:
#lang racket
(require pict/tree-layout)
(define (complete d)
(cond
[(zero? d) #f]
[else (define s (complete (- d 1)))
(tree-layout (and s (tree-edge #:edge-color "red" s)) s)]))
(naive-layered (complete 4))
(binary-tidier (complete 4))
Ah! OK, that makes sense.
At the time I wrote that, I was forgetting that the #f
nodes weren't drawn, but remembering the line "The default node-pict
(used when it is #f
) is..." from tree-layout
's docs. If you don't mind, in submitting the doc fix you've suggested for this, I'm going to change that "it" to node-pict
, lest any other space cadet think "it" refers to the child rather than the pict.
Wonderful, thank you!
I also think we need to chagne the contract from (the internal) tree-layout?
function to (and/c tree-layout? (not/c #f))
so that the error messages come out right and match the docs.
(using the external tree-layout?
function in the second contract)
OK, commit c088bb028865bf824651be5f515a66c0dc758f41 has those changes.
And 5c4726bf5854452d5749c636d72c6939772646e1 has the internal fn on the actual (not docs) contract.
In the
pict/tree-layout
docs, thetree-edge
function is specified as taking atree-layout?
, which in turn is defined to be#f
or the output of thetree-layout
function. However, thetree-edge
contract given inpict/tree-layout.rkt
is not sufficiently permissive to allow#f
as an input:The practical consequence is that this appears to prevent the creation of a binary-tree-layout with one or more individually customized edges.
The immediate cause is that the
tree-layout?
given as first input in the contract is the struct type predicate fromprivate/layout.rkt
, and not the more permissive_tree-layout?
function available to client code. Making the input be_tree-layout?
does fix the immediate problem and allowtree-edge
to take#f
; however,naive-layered
andbinary-tidier
fail to render trees created that way:The
hv-alternating
function does correctly render the resulting trees.