Arrows v1.0.0

[phoe]

This commit overhauls Arrows and brings them to v1.0.0.

• The code is rewritten.
• All arrow macros now expand into let*.
• The arrows some-<>, some-<>>, cond-<>, cond-<>> are added.
• The Markdown documentation is updated.
• The documentation strings are updated.
• A Markdown tutorial for arrow macros is added.
• The test suite is expanded.

Fixes #2.

TODOs remaining:

• Implement setf expanders for arrows - see Are arrow macros valid places? #4
• Finish the tutorial
• Add more examples

I'll request code review for this commit from #lisp and from the Lisp Discord.

Since the code was massively rewritten, it might be better to view the whole resulting repository at https://github.com/phoe-trash/arrows rather than try and view the diff for this change.

[phoe]

An issue highlighted by fiddlerwoaroof on #lisp is that (->> (expensive) (or t)) no longer quickly returns t after this change. I don't yet know how to handle this.

[phoe]

Yes, there's a problem. My current implementation of arrows makes the assumption that each form passed to the threading macro is going to be evaluated; splicing such a form into a form with special evaluation rules, e.g. a macro, breaks this assumption.

And now that I think of it, this is un acceptable from an implementation of arrow macros. Clojure's arrows are syntactic sugar and therefore they are capable of operating even on data that makes no sense when it is evaluated; my rewrite breaks this assumption and therefore is not backwards compatible.

Because of this, sorry, I'll need to close this PR. I will publish my code as a separate system with different semantics.

[Harleqin]

Well, thanks for the research and effort anyway!

[digikar99]

Would it be a good sense to keep the default-optimization quality expansions as they are; but when debug is 3 (or some other optimization condition), the expansions are made in accordance with binding-arrows, since better debugging was the sole purpose of binding-arrows?

[phoe]

This is a bad idea. Optimization qualities must not change the semantics of the program, and (-> foo (defun (bar) (1+ bar))) has different semantics under arrows and binding-arrows.

• In case of the former, it defines a function named foo;
• In case of the latter, it may signal an unbound variable error if foo is not globally bound, attempts to define a non-toplevel function with an unpredictable gensym name, and shall also signal an unused variable warning.