-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
:=
macro equivalent?
#46
Comments
We are considering compatibility with
|
you mean prefix, right? |
@xificurC can you give me an example of what you mean by this? |
Sure. The examples on the homepage like {:a :b, :b [2 :b]} := {:a _, _ [2 _]} look very nice, but once your test doesn't nicely fit on a single line, how do you align it to look well? {:a :b, :b [2 :b]}
:=
{:a _, _ [2 _]} This leaves a whole line for the poor {:a :b, :b [2 :b]}
:= {:a _, _ [2 _]} or {:a :b, :b [2 :b]} :=
{:a _, _ [2 _]} are just hard to read, especially when the code is bigger, one has to search for the With a prefix operator this problem is solved (assert= {:a :b, :b [2 :b]}
{:a _, _ [2 _]} |
Thank you! You're right, we do write trailing := a bit. So many people are asking for this that we are possibly willing to reconsider. So if I can follow up: How would you write repl-style code that uses bindings to *1 etc?
Note you don't want *1 to be bound to the result of the assertion, you want it bound to the LHS. Should we change the rules of *1? |
Here are some real world tests from our codebase - Photon compiler https://gist.github.com/dustingetz/12a6eb81e585942e277b4bec47d98dd5 Missionary m/cp explanation https://gist.github.com/dustingetz/9f8f8ae739fc6efc70f4f5855817b85d and of course in the wild https://github.com/clojure/core.unify/blob/e2ae03c08b45528f3274d154a8f4625e7acbeccd/src/main/clojure/clojure/core/unify.clj#L246-L358 |
The "in the wild" example doesn't seem to be using RCF?
Care to elaborate how does infix notation pose challenges to this? If If you're thinking of changes in a broader sense I'd like to propose to allow third-party extensions like matcher-combinators or https://github.com/lomin/sinho to integrate into rcf. It would also be nice to get reporting right |
If you paste Thanks for the sinho and matcher combinators links, we definitely feel the need for m/embeds etc, happy to document and support the best patterns after #50 ships. Thanks for the ideas regarding reporting - can you please open a new issue for reporting and specify exactly how reporting should work? |
I thought you are already hacking the REPL bindings? user=> (keyword "B") := :a
:B
:=
:a
user=> *1
:a Pasting the infix check into the REPL doesn't bind the result of |
Our worldview is that in this real-world RCF: ; https://clojuredocs.org/clojure.core/map
(map inc [1 2 3 4 5])
;;=> (2 3 4 5 6) To learn what this does, you send this to the repl: The point of the RCF is to document what the target does (as if in a tutorial) without altering the target |
I don't think you documented what RCF stands for and I don't know what the acronym means, care to define it for me? Thanks! The "REPL bindings work" example test you posted shows that |
Ah the question is not can we do it, the question is what is the least surprising behavior. Consider: in The root cause of the mess is that the testing boilerplate has infected the target expression. RCF means rich comment form |
I understand now, thanks. I see a couple of options:
But the point of the library is to test, you can't consider it boilerplate! :) Anyway, there are other alternatives too (testing (keyword "B")
(= :B)
(= (namespace %) nil)
(= (name %) "B")) Off the top of my head :) |
The infix
:=
operator, while looking nice, can be problematic. First of all it's impossible to align code correctly with it. Secondly there are edge cases like #40 and #42 where the expansion isn't working currently. Thirdly some people might prefer a more lisp-y style of defining the assertions.Would it be complicated to allow asserting manually? Something like
The text was updated successfully, but these errors were encountered: