Expose deleted-signal with docs correction #13

@mbutterick The docs say that (λ (x) null) is the default replace-proc for splitf-txexpr.
This disagrees with the code, which uses deleted-signal. Since there is a use case for conditionally removing elements, I put in a (provide deleted-signal) and corrected the docs.

@mbutterick The docs say that `(λ (x) null)` is the default `replace-proc` for `splitf-txexpr`. This disagrees with the code, which uses `deleted-signal`. Since there is a use case for conditionally removing elements, I put in a `(provide deleted-signal)` and corrected the docs.

I don't know if I can speak to the CI build error:

Resolving "sugar" via http://download.racket-lang.org/releases/6.0.1/catalog/
ssl-connect: connect failed (error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure)

I don't know if I can speak to the CI build error: ``` Resolving "sugar" via http://download.racket-lang.org/releases/6.0.1/catalog/ ssl-connect: connect failed (error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure) ```

I see what you mean. The docs are wrong, at least. But IIRC deleted-signal is meant only for internal housekeeping, so adding it to the public interface is probably not quite the right fix.

Intuitively it seems like the default value for replace-proc should be #false — I can’t remember why I didn’t do it that way before, but I’ll look into it.

I see what you mean. The docs are wrong, at least. But IIRC `deleted-signal` is meant only for internal housekeeping, so adding it to the public interface is probably not quite the right fix. Intuitively it seems like the default value for `replace-proc` should be `#false` — I can’t remember why I didn’t do it that way before, but I’ll look into it.

Ok. For convenience I went ahead and set deleted-signal to #f in the code and docs and reverted the interface change. raco test test/tests.rkt still passes if that helps.

Ok. For convenience I went ahead and set `deleted-signal` to `#f` in the code and docs and reverted the interface change. `raco test test/tests.rkt` still passes if that helps.

@mbutterick keep-alive ping + update. git bisect names dfe91a390d as gensym's origin. I was hoping to find enough context to write test cases for this PR. So far the only corner case I see is that splitf-txexpr breaks its own contract when it tries to replace the entire element provided to it, but that is existing behavior that reproduces regardless of deleted-signal's value.

So, two questions:

I'm happy to take on the work of writing tests for any corner cases, but what would they be in the scope of this PR?
If the answer to 1. is "no", is this PR good to merge now that I use #f (Assuming the CI build error is not in scope)?

@mbutterick keep-alive ping + update. `git bisect` names dfe91a390db098f77042df30f49b5fa1b5a22cb7 as `gensym`'s origin. I was hoping to find enough context to write test cases for this PR. So far the only corner case I see is that `splitf-txexpr` breaks its own contract when it tries to replace the entire element provided to it, but that is existing behavior that reproduces regardless of `deleted-signal`'s value. So, two questions: 1. I'm happy to take on the work of writing tests for any corner cases, but what would they be in the scope of this PR? 2. If the answer to 1. is "no", is this PR good to merge now that I use `#f` (Assuming the CI build error is not in scope)?

Thanks for the reminder. Let me look at this in the next couple days and I will finish it off or present further questions.

Thanks, let’s see what happens 🤘

Thanks, let’s see what happens :metal:

Labels Milestones

Expose deleted-signal with docs correction #13

Step 1:

Step 2: