> > notice how in Haskell there is a strong will to
> > group things together. That's what you'd take out
> > of the example.
>
> Of course.  In Haskell and in life generally.  Things
> that are alike generally belong together.
>
> But this discussion is about _naming_ functions, vars,
> etc., not just grouping them.  In Elisp, grouping them
> in a library already gives them a library prefix.  And
> in general that has nothing to do with the type of
> objects they use or return.

No, to me this discussion is about _grouping_ things, that's why we push
for library prefixes.

> It can make sense to adopt a prefix convention for
> functions that define a type of thing (e.g. buffer,
> window, vector, string) than it does to impose it
> willy-nilly way on functions that might just return
> such a thing or accept it as one of their args.

Just to be clear, "type-grouping" you more or less see the point but
"topic-grouping" (e.g regexp, string) not so much?

> Most functions do not fit that bill of defining a
> thing type.  And many (most?) do not fit the bill
> of acting only/mainly on one particular type of
> thing or having as their main purpose to return
> such a thing.
>
> That was really the point.  Perhaps there are some
> cases in Elisp where it would make sense to prefix
> more functions that involve a particular kind of
> thing.  I've acknowledged that.  And others have
> said the same thing, citing strings as a type that
> might be looked at more in this regard.

Okay, but I think we already agree on this? I propose to alias/rename
functions where it's "obvious", but as we saw that what is obvious for me
is not obvious for everyone, so that's complicated. I think we reached a
point where everything proposed was rejected so this is a dead end.

> The corner cases for me are the relatively few
> functions whose names cry out for labeling as
> specific to some type, and I'd propose fixing
> their names, case by case.

The ones I proposed were all rejected :-/ Do you have one in mind?