Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> writes:
> The macro system can help you here. For example, if you look into Chez
> Scheme's source code, there is the syntactic keyword
> define-syntactic-monad defined, which allows you to write procedures
> and call them with implicit arguments without compromising speed.

Yes. I have also implemented a similar facility.

This is not an implementation problem, it's a design topic.

I have made very many wrappers and combinators and syntax-layers to be
able to better deal with cumbersome interfaces like this. Here is my
chance to prevent an interface from being cumbersome in the first place.

> Applying this to comparators would mean that you pass a specific comparator
> as a parameter (fluid binding, whatever). This would let you get rid of CPS
> but you would only sacrifice a bit of efficiency.

Right. Either side can ask the other to use fluid binding, or, there can
be two versions of the procedures. If the latter, the question becomes
what name to use for them.

> It could if =? weren't already specified

Yes, that is the problem.

Howeve, as you noted:

> SRFIs can be revised, so nothing which is specified by SRFI 128 has to
> be set in stone for eternity.

That's why the one and only case I am making for here is to reconsider
this naming decision.

> and if both would be equally well in terms of good programming style.
> :)

Here are some possible interfaces for a comparison combinator that
requires a comparator as an argument.

Note that the output and input of `frobnicate` would not be the same in
these options.

• (=? (frobnicate) x y)
• ((frobnicate) x y)
• ((frobnicate =?) x y)
• ((=? (frobnicate)) x y)
• (((frobnicate) =?) x y)

There is some amount of pointlessness to the first option, only looking
at the types of x and y to fish out from (frobnicate) what comparator to
actually apply to x and y.

The second option queries for an equal-comparator directly. (Others
would similarly query for <? and friends.)

The third option, or ((frobnicate '=?) x y) similarly, can dispatch to
know what type of comparison is requested, as can the fourth and fifth
options.

Common among options 2 through 5 two things: the generated comparator
can be bound directly (whereas the first option can with a lambda, cut,
or similar), and that it has argument homogenity, which is suitable for
maps, counts and similar.

Not every procedure I define has argument homogenity, or whatever we
wanna call it, I don't know a formal name for it because it's my own
observation and experience that a lot of things goes a lot more smoothly
and comfortably when we do happen to have it.

I mean, the <?/with-default-comparator (or, as SRFI-128 calls it, <?),
is not even possible to pass directly into a sort.

It breaks the conventional interface of <, string<? &co.

The above is not to argue for option 2 to 5. My proposal is to use the
default comparator registration facility. The above is just to kind of
show that in this interface:

• (=? (frobnicate) x y)

=? is reduced to being basically just a combinator, and a cumbersome and
impractical one at that. The real magic happens inside of (frobnicate).

This is not good programming style.

The intent here is to find the =? associated with the type class data
queried by (frobnicate).

If that is the intent, then it is not only backwards compare to
((frobnicate =?) x y), or I guess if you wanna see it like a
multimethod/generic, in which case ((=? frobnicate) x y) would be an
option, it is also level-conflating or whatever you wanna call the
"argument heterogenity" I've been complaining about above.

John can speak for himself (of course), but it seems to me that the intent
with making the comparators optional was to enable things like

(sort xs <?)

and that the removal of that optionality/dispatchingness, as an
afterthought, led to an interface that was different and more cumbersome
than if the SRFI had been designed around the explicit passing of
comparators.

As it is, it reads completely cart before horse.

To me, it seems like the entire point of creating comparators as a type
would be to be able to register it as a default.

In the SRFI, the comparators are implemented as record objects and the
internal interface uses things like

((comparator-equality-predicate comparator) x y)

where comparator-equality-predicate is a record accessor.

An idiomatic and classic style.

Uh, I wrote all the frobnicate stuff above before I went and looked at
this, but, it's interesting to me that my intuition on how to do it
(with frobnicate) matches how it's done internally here.

It's just that (=? (frobnicate) x y) is not a convenient interface. It's
the opposite of currrying, it's an un-curried interface.

It turns ((foo-prime bar) x y) into (foo bar x y)

That is not good programming style.

Instead, turning ((foo-prime bar) x y) into (foo x y) is good style,
even when bar is a extensible object.

Allowing

(=? x y)

is the essence of generic programming, generic methods.
Which I like.

If you don't want generic methods, if generic methods are unwanted,

(=? c x y) is not a good interface.

Instead, (equal? x y) is probably what you want, or (sprite=? x y),
(hat=? x y), ((find-my-equals) x y), (my-cps-passed-c x y), or similar.
Or fluid-let. You wouldn't've needed to bother with the whole (=? c x y)
schtick in the first place.

Providing a generic comparator facility only to then not provide a
generic comparator facility does not feel super useful to me.

Additionally, I very much appreciate remarks like the following:

> Anyway, please don't feel scared by the way things are discussed here. It
> is never about you as a human being but just about questions that exist
> independent of who has raised them.

Thank you for that.