unpack-iterable and macros

[wrobell]

I believe that conclusion of ticket #1730 is that unpack-mapping is not supported because positional arguments are supported by macro definition only (even for optional arguments).
What about unpack-iterable?

Asking for the following problem... maybe there are alternatives?

Consider

(defmacro fn/f [func #* args]
  `(fn [v] (when (~func ~@ args v) v)))

(defn filter-func [v] (< 5 v))

(defn [(pytest.mark.parametrize "filter,arg,expected"
        [#(filter-func 6 6)          # testing call: ((fn/f filter-func) 6)
         #(filter-func 4 None)       # as above
         #('(< 5) 6 6)               # testing call: ((fn/f < 5) 6)
         #('(< 5) 6 None)])]         # as above
      test-filter-pass [filter arg expected]

  (setv result ((fn/f filter) arg))
  (assert (= result expected)))

The following fails because unpack-iterable is not supported for macro it seems

(setv result ((fn/f #* filter) arg))

Or is it better way of implementing this test (without creating additional test functions)?

[Kodiologist]

I don't get it. If (fn/f filter) works and does what you want, then why do you want to say (fn/f #* filter), and what do you expect it to do? Maybe a simpler example would help.

[wrobell]

I want fn/f to accept

(fn/f some-bool-func)
(fn/f < 2)
(fn/f another-bool-func 1 2)

And I would like to have parametrized unit test for calls like above.

To generalize my example

(defmacro fn/f [func #* args]
  `(fn [v] (when (~func ~@ args v) v)))

(defn filter-func [v] (< 5 v))

(defn [(pytest.mark.parametrize "filter,arg,expected"
        [#(`(filter-func) 6 6)          ; testing call: ((fn/f filter-func) 6)
         #(`(filter-func) 4 None)       ; as above
         #('(< 5) 6 6)                  ; testing call: ((fn/f < 5) 6)
         #('(< 5) 6 None)])]            ; as above
      test-filter-pass [filter arg expected]

  (setv result ((fn/f #* filter) arg))
  (assert (= result expected)))

At the moment #* is not supported for macro arguments. Would that be a good use case for it? Or maybe there is other way I could implement this unit test without creating two additional functions?

(btw. similar technique could be used for hyrule unit tests if i remember well)

[Kodiologist]

You have more basic issues. # isn't a comment character, and you need (import pytest) to use pytest.mark.parametrize. See also the tips for using pytest with Hy.

[wrobell]

1. Changed # to ; above to avoid confusion (these comments are added only for the purpose of this discussion). Old habits die hard.
2. No problem running or defining unit tests on general level, see the code in question here: https://gitlab.com/n23/n23/-/blob/lisp-flow/n23/pipeline/tests/. Your page is very basic and it does not discuss parametrized unit tests. Actually Hy itself uses it very little, and Hyrule not at all. And for sure some-> unit tests could benefit here.

I recognize I am still mixing up macro/function worlds. If I understand well

1. For example, the form '(< 5) is known at the module level.
2. But then goes through pytest and function definition layers, so that information is lost when expanding macros within the unit test case.
3. When the unit test case is called, then macros are already expanded/compiled, so if any argument unpacking would be possible, then it would happen on runtime in the lambda defined by fn/f.
4. Therefore, the test would not check what I exactly want to check - passing multiple arguments to the macro itself.

At this stage I don't expect to get some neat conclusion for this discussion. I think I can get away with one additional function. Hopefully one day some smart, more interesting solution can be found.

@Kodiologist The discussion, while not exactly constructive, pushed me to think more about the problem. Thanks. I hope others will still find it interesting.

[Kodiologist]

Your page is very basic and it does not discuss parametrized unit tests.

That page is for documenting Hy-specific issues. Parametrization via pytest.mark.parametrize should work exactly the same in Hy as in Python.

I recognize I am still mixing up macro/function worlds.

Yes, as I understand your example, you're trying to splice the run-time variable filter into a macro call. The macro is expanded at compile-time, when filter is just a symbol. If you want to expand at run-time instead, you could say

(setv result (hy.eval `((fn/f ~@filter) ~arg)))

Or, instead of using pytest.mark.parametrize, which resolves at run-time, you could build the four test functions yourself with metaprogramming.

[wrobell]

Thanks. hy.eval was the missing bit.

[wrobell]

And bit more complicated version where I test defn/p macro, which needs to involve use of locals

(defmacro defn/p [name #* args]
  `(setv ~name (fn [v] (hy.R.hyrule.some-> v ~@args))))

(defn [(pytest.mark.parametrize "filter,arg,expected"
        [#('(filter-func) 6 6)
         #('(filter-func) 4 None)
         #('(< 5) 6 6)
         #('(< 5) 4 None)])]
      test-filter [filter arg expected]
  (setv env (locals))
  (hy.eval `(defn/f check ~@filter) :locals env)
  (setv check (get env "check"))
  (setv result (check arg))
  (assert (= result expected)))