I can only agree with you here. The code does not only become easier
to read, it will also eliminate an irregularity, which is always good:
Without any exceptional rule, no "<>" would read as "zero values",
which, while probably not used very often, would be the obvious
meaning.

The regular version with no values has some uses for thunks.

(chain-lambda (a) (b <>))

would translate into the thunk (lambda () (b (a))).

(If one really thinks that a macro with an implicit "<>" is needed,
such a macro should be some supplementary macro, e.g. chain-last, and
not one of the central macros in this SRFI.)

Am So., 9. Aug. 2020 um 08:46 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > In Clojure I use threading macros often, but one thing that always
> > bothers me is that the argument position is implicit (for most of the
> > family of macros).  It is ok while working on it, but once I leave the
> > coding for a while and then look at the code, it's extremely confusing.
>
> +1
>
> > I ended up always marking the inserted argument position with commas,
> > which are treated as whitespaces in Clojure.
> >
> > srfi-197 allows to use <> as the insertion points, and I can always use
> > it even the argument position is the last position:
> >
> >    (chain (a b) (c d <>) (e f <>))
>
> This is a nice notation.
>
> I've always found the <> marker a bit confusing since it stands for "not
> equal" in Pascal and many other languages. But it's inherited from SRFI
> 26 `cut` and `cute` which I guess set a strong precedent. Starting from
> scratch, I would prefer underscore which is a placeholder marker in many
> languages:
>
> (chain (a b) (c d _) (e f _))
>
> > And I wonder if we gain anything by allowing <> in the last position to
> > be omitted.
> >
> > Sure it may shorten the code a bit.  However, the spec is effectively
> > the same as  "show the argument position with <> except when it's the
> > last position, in which case you can omit it."    It looks somewhat an
> > arbitrary and irregular rule.
>
> +1
>
> > Code is read far more times than written.  Saving a few keystrokes
> > trading off readability doesn't seem a good deal.
> >
> > Is everyone comfortable with implicit argument?  Certainly, when I see
> > (cons "x"), I can see there's an implicit argument, since the fact that
> > cons takes two arguments is engraved in my brain (the same circuit fires
> > when I'm reading Haskell code).
> > But it isn't always necessary the case, e.g. (list 'a 'b)
>
> Good point.