Should arrow-macros be replaced with https://gitlab.com/Harleqin/arrows?

[Ambrevar]

I haven't tested though.

[Hexstream]

For whatever it's worth, I don't think arrows should be recommended as awesome, personally.

[Ambrevar]

I don't know if the purpose of Awesome CL is really to stick to just "awesome" libraries, I believe we have a number of unpolished, debatable libraries in the list. Clojure users could be happy to know that such a feature exists in Common Lisp and this might help with conversion. We could also include the discussion you've linked next to the recommendation. This is already what we are doing for a number of recommendations, I believe transparency is an essential goal for "curated" lists.

[Hexstream]

I don't know if the purpose of Awesome CL is really to stick to just "awesome" libraries, I believe we have a number of unpolished, debatable libraries in the list

🤔 (I don't have time to review third-party stuff, so I wouldn't know...)

Clojure users could be happy to know that such a feature exists in Common Lisp and this might help with conversion.

There is an interesting balance to strike between identity(+)/tribalism(-) and outreach(+)/pandering(-).

We could also include the discussion you've linked next to the recommendation.

Thank you for the proposal, it would definitely be far beyond my expectations if this was implemented.

This is already what we are doing for a number of recommendations, I believe transparency is an essential goal for "curated" lists.

💯

[vindarel]

arrow-macros seems to be more featurful that Harlequin's arrows: it works with nested arrows (but does it really need a code walker?), and has more forms (as explained in arrows' README). It seems the least surprising solution. I am not a big user of arrows either.

[Ambrevar]

OK, then let's stick to arrow-macros, then. Thank you @vindarel for clarifying the differences.

[phoe]

(but does it really need a code walker?)

Yes.

The arrow macro processing function must know if <> is used as a variable anywhere in code in order to decide if it should take the path that binds <> as a variable or if it should take the path that uses -> or ->> to thread the value into the next expression.

This problem cannot be solved in Common Lisp without a code walker, and this is why arrows has a simpler implementation of <> that does only permit the use of <> at the outermost level. arrows and arrow-macros have full feature parity other than the above quirk.

[phoe]

But wait a second, I have just noticed that Clojure's swiss-arrows do not permit the diamond to be used in nested context! swiss-arrows only checks for the diamond on the outermost level.

For instance, the following Clojure code is invalid:

(print (-<> 42 (list (list <>))))

;; Syntax error compiling at (test.clj:166:22).
;; Unable to resolve symbol: <> in this context

Therefore the behavior of arrow-macros that walks the code in search for variable references is an extension and superset of swiss-arrows. This also means that arrows already have full feature parity with swiss-arrows and, similarly, does not require a code walker.

[Harleqin]

Yes, the arrows README could maybe make this a bit clearer in the comparison paragraph.

[phoe]

I am currently overhauling arrows to have easily human-readable macroexpansions by means of expanding into a let* - a feature that arrow-macros doesn't have at the moment. This should help people who have problems reading code with arrow macros and would rather macrostep through them in order to be able to read the flow better.

I'll also revamp the documentation and README in the process.

It might therefore be preferable to include both to provide choice for people:

• arrows that has readable expansions (as soon as my PR is merged) and no heavy-weight dependencies,
• arrow-macros that has diamonds that work with nested forms,
• cl-arrows noted only to mention that it should not be used, due to licensing issues and being unmaintained.

---

EDIT: The rewrite, sadly, did not work; the let* transformation I attempted to perform is invalid in the general case. See Harleqin/arrows#3 for rationale.

[phoe]

Due to the semantic differences between the original arrows and my attempt to rewrite them, I have instead published a new library at https://github.com/phoe/binding-arrows that contains a complete test suite and a tutorial suitable for threading macros in general.

If someone is fine with threading only Lisp values, as opposed to syntax elements in general, I assume that my implementation could be of use to them and therefore mentionworthy. But, ultimately, that's not for me to decide.