Re: [External] : Re: Shrinking the C core

[Emanuel Berg <incal@dataswamp.org>]

Yuri Khan wrote:

> 1. a couple of functions
>    a. ‘(my-sort-by SEQ LESSP)’ where LESSP is a function accepting two
>        elements X and Y and returning ‘t’ when X should be
>        sorted before Y, and
>    b. ‘(my-sort-on SEQ KEY)’ where KEY is a function accepting an
>        element X and returning a number such that sorting by
>        that number yields the desired order; or
>
> 2. a single function that could be called as ‘(my-sort SEQ
>    :by LESSP)’ or ‘(my-sort SEQ :key KEY)’, with the same
>    semantics as above?
>
> Does your answer change if we want to extend the API to also
> support sorting in descending order? If it does, how?

If there are several tendencies and in particular if those can
be combined one can absolutely use keywords (and extend by
adding more), but then we are at a level of complexity which
would translate to a huge amount of envisioned simple, one or
two argument functions, so instead of doing that, if one were
to stay at the simple function end of the spectrum, one would
use combinations of such simple functions, e.g.
(reverse (sort ... ))

At the opposite end where functions are insanely complex,
keywords are a way to make the interface more clear and
facilitate the submission of arguments from code.

So it is good keywords exist when it is complicated, in
general I prefer it when it is simple but sometimes the
complexity is such it is actually easier to not try to keep it
simple - since that is impossible - but to stay at the complex
side and take it from there.

Optional arguments don't really belong on that simple/complex
scale, rather they should be used when there is an intuitive
default, for example (forward-line &optional N) where
N defaults to 1.

-- 
underground experts united
https://dataswamp.org/~incal