Implement when-some, if-some, with-open, doseq etc

[vemv]

Context

speced.def is designed with toggleability in mind. One can add or remove speced/(those literal 7 chars) to existing forms written in vanilla Clojure and get desirable properties in exchange.

That proposition is true for defn, defprotocol, let, etc but not for others like if-let, when-some, when-let, if-some, with-open, doseq, binding... basically anything that expects a binding. Also ->, ->>

That limitation was there for no strong reason, simply the latter group is less frequently used and I was inclined to "start small". After time has shown no problems for speced.def's approach, it seems a good idea to expand the offered "speced" forms.

Importantly, this allows a fully automated rewriting from non-speced to speced, using no fine-grained reasoning or noisy (possibly incorrect) manual changes.

Example use case

I want to address reflection warnings in a project that doesn't use speced.def.

I create a PR that simply adds type hints. But for QA purposes, in a separate branch I also add speced/ in all the surrounding forms so that I'm confident that the type hints are veridic.

This adding of speced/ to forms like with-open, binding etc is automated via rewrite-clj.

Task

Create the mentioned speced forms.

I foresee each form's impl would be quite thin, see e.g. let's https://github.com/nedap/speced.def/blob/4d2982a546fb671952f4b3833b854eb3751a6f67/src/nedap/speced/def/impl/let_impl.cljc

Acceptance criteria

The mentioned forms are implemented with the usual test coverage

[thumbnail]

Thanks for the issue, this seems like a good suggestion!

It's a good idea to make a definitive list of the supported / unsupported macros (especially interested in the latter).

Total sidenote; we might be able to implement (some of) these clojure.core macros in a way that works for third party macros too (given a similar shape)

[vemv]

It's a good idea to make a definitive list of the supported / unsupported macros (especially interested in the latter).

Good call, it's good to agree on a goal and try catching some possible non-goals

Total sidenote; we might be able to implement (some of) these clojure.core macros in a way that works for third party macros too (given a similar shape)

Sounds good, I'll try to keep an eye for genericity.

As far as tests are concerned, I'd try to keep tests just as exhaustive as currently for each form. Even if that means some duplication / relatively long testing namespaces.

My thinking is that replacing clojure.core forms is a really strong commitment to make, so we should guarantee it works. "All these macros are based on x, x is correct so the macros are correct" would seem a pretty reckless thing to do for this kind of lib.

(Of course, if some third party decided to use our hypothetical 'macro builder', it's up to them how they test it)